Re: View to get all the extension control file details - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: View to get all the extension control file details
Date
Msg-id 20181022.171254.161649179.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: View to get all the extension control file details  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List pgsql-hackers
Hello.

At Wed, 17 Oct 2018 18:38:05 +1100, Haribabu Kommi <kommi.haribabu@gmail.com> wrote in
<CAJrrPGdyJ=a=Aqu6Uzz2CsFt+erzg4GH15SaYU6uUPYpqkaj1Q@mail.gmail.com>
> On Sat, Oct 13, 2018 at 3:57 AM Robert Haas <robertmhaas@gmail.com> wrote:
> 
> > On Wed, Oct 10, 2018 at 8:27 AM Haribabu Kommi <kommi.haribabu@gmail.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.

FWIW, I came to feel that pg_stat_activity getting too bolder a
bit in both width and hight. I'm accustomed to type extra "where
backend_type like 'client%'":p

> 
> >   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.

I'm not sure I understand correctly, it seems that the problem
raised is not data dependency but schema evolution, or schema
dependency. (Anyway we cannot restore a view data in a straight
way.)

> 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?

It may be an EA->V function. Specifically pg_extension_info(name
text, attr text) returns text. Or may be such like
pg_get_environment_info(category text, name text, attr text), where category
would be 'extension' in this case.

=# select name, version,
       pg_get_environemnt('extension', name, 'encoding') as encoding
   from pg_extension;

If we enforce user views to use the function by, say, not
bundling system view using it, such views won't complain during
restoration. (May complain at runtime later, though.)

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: Buildfarm failures for hash indexes: buffer leaks
Next
From: Masahiko Sawada
Date:
Subject: Re: Function to promote standby servers