From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Joel Jacobson <joel(at)trustly(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: The missing pg_get_*def functions |
Date: | 2013-05-06 12:01:02 |
Message-ID: | m261ywqpvl.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-04-30 05:14:15 +0100, Joel Jacobson wrote:
>> It would be better to find a way to update sql-language functions in
>> minor upgrades, instead of shutting that door entirely for all future
>> implementation ideas involving sql-language functions in the
>> pg_catalog.
>
> I'd be very careful with jumping on this task. I am pretty sure its a
> very good way to get very, very frustrated if you don't present a widely
> accepted design beforehand. Doing this correctly is *far far* from easy.
>
> 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).
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.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2013-05-06 12:31:54 | Re: The missing pg_get_*def functions |
Previous Message | Alexander Korotkov | 2013-05-06 11:10:05 | Re: Terminology issue: suffix tree |