Re: View to get all the extension control file details

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: View to get all the extension control file details
Date: 2018-10-17 07:38:05
Message-ID: CAJrrPGdyJ=a=Aqu6Uzz2CsFt+erzg4GH15SaYU6uUPYpqkaj1Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Oct 13, 2018 at 3:57 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, Oct 10, 2018 at 8:27 AM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
> wrote:
> > Here is the patch as per the above discussion.
>
> One potential problem with this is that we could add more control-file
> attributes in the future, and it will be annoying if the view ends up
> with a million columns, or if we ever have to rename them.

Yes, there is a problem if we add more attributes or rename them.

> People who
> have created objects that depend on those views may find that
> pg_dump/restore or pg_upgrade fail, just as they do when we whack
> around pg_stat_activity. pg_settings gets around that using an
> EAV-like format. I'm not sure that's the best solution here, but it's
> something to think about.
>

similar like pg_settings view, so displaying all the data without validating
them from pg_extension may solve the problem.

Other idea to avoid this problem is, how about displaying the extra columns
using JSONB
data type, so that all the extra additional columns that are not important
will go to that column?

Regards,
Haribabu Kommi
Fujitsu Australia

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Victor Wagner 2018-10-17 07:47:01 Building 64-bit postgres with GSS support on windows
Previous Message Andres Freund 2018-10-17 06:53:04 Re: [PATCH] heap_insert() and heap_update() optimization