Patch applied. Thanks.
---
Andrew Dunstan wrote:
>
> This patch implements putting language handlers for the optional PLs
> into pg_catalog rather than public, and supports dumping languages whose
> handlers are found t
This patch implements putting language handlers for the optional PLs
into pg_catalog rather than public, and supports dumping languages whose
handlers are found there. This will make it easier to drop the public
schema if desired.
Unlike the previous patch, the comments have been updated and
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Yeah. I think we'd need to add "where langlcallfoid != 0" so we don't
pick up the internal/C/sql handlers. However, on closer inspection it
appears that doind all this in pg_dump would be lots more invasive than
I first thought.
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Yeah. I think we'd need to add "where langlcallfoid != 0" so we don't
> pick up the internal/C/sql handlers. However, on closer inspection it
> appears that doind all this in pg_dump would be lots more invasive than
> I first thought.
Why --- what el
Tom Lane wrote:
regression=# explain analyze select * from pg_proc WHERE NOT proisagg AND (pronamespace != (select oid from pg_namespace where nspname = 'pg_catalog')
regression(# OR oid in (select lanplcallfoid from pg_language) OR oid in (select lanvalidator from pg_language));
Yeah.
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> This won't work - it would miss the validators. Slightly more complex
> than I thought.
Well, there's always the brute-force solution:
regression=# explain analyze select * from pg_proc WHERE NOT proisagg AND
(pronamespace != (select oid from pg_name
On 2005-06-24, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Is there any reason for us to keep putting the language handler
>> functions in the public schema?
>
> I believe one of the issues there is that pg_dump doesn't dump functions
> that are in pg_catalo
I wrote:
Hmm. Could we not just add something this condition:
or pg_catalog.format_type(prorettype, NULL) != 'language_handler'
in pg_dump.c around line 2191?
This won't work - it would miss the validators. Slightly more complex
than I thought.
cheers
andrew
---
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Hmm. Could we not just add something this condition:
> or pg_catalog.format_type(prorettype, NULL) != 'language_handler'
> in pg_dump.c around line 2191?
You forgot about the validators, which are not so easily identified.
rega
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Is there any reason for us to keep putting the language handler
functions in the public schema?
I believe one of the issues there is that pg_dump doesn't dump functions
that are in pg_catalog. You could possibly fix it to m
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Is there any reason for us to keep putting the language handler
> functions in the public schema?
I believe one of the issues there is that pg_dump doesn't dump functions
that are in pg_catalog. You could possibly fix it to make an exception
for funct
Is there any reason for us to keep putting the language handler
functions in the public schema? If they were put in, say, pg_catalog (as
I see Peter's pl/sh language does for its handler) then the public
schema could be dropped by people who want to do that with no ill
effect, AFAICS.
cheer
12 matches
Mail list logo
