Re: The missing pg_get_*def functions - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: The missing pg_get_*def functions
Date
Msg-id 20130506123154.GB4361@tamriel.snowman.net
Whole thread Raw
In response to Re: The missing pg_get_*def functions  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: The missing pg_get_*def functions  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
* Dimitri Fontaine (dimitri@2ndQuadrant.fr) wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > Just a little collection of problems:
> > * You need to connect to all databases, not just one. There's no
> >   infrastructure for this.
>
> I wonder if it wouldn't be possible to have a per database catalog
> version and do the work either at first database connection or first use
> of the modified function, with some more smarts (catversion changed, and
> a list of tableoid, oid changes in the catalogs somewhere).

I like the idea of having a per-database catversion, but we'd have to
have a cluster-wide version for the shared catalogs too.  I don't think
it's a good idea to wait until the first connection to a DB to apply the
update either..  My thinking was that we'd just kick off a backend for
each database (perhaps using the background worker structure) which
would then apply the update and exit, while the postmaster would wait
until all of these workers have finished before allowing general
connections.

> But basically, that means that I agree that doing this correctly is very
> far from being easy. And maybe improving the extension feature list is
> an easier way forward.

It likely is, but it would really be nice to be able to do catalog
updates like these in a better fashion than sticking some update command
into the release notes and hoping that someone reads them and runs the
command..
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: The missing pg_get_*def functions
Next
From: Dimitri Fontaine
Date:
Subject: Re: The missing pg_get_*def functions