Re: Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog, - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Date
Msg-id 4992BDA1.30506@gmx.net
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Note that it introduces a LEFT JOIN on pg_class to itself that's always
>> present, even for server versions that do not support reloptions.
> 
> Personally I'd be more worried about the unnest().  Also, please
> schema-qualify that function name; you can't assume anything about
> the search path here.

Maybe it would be more elegant to put the search_path into proconfig? 
This would have some advantages:

0. Looks less weird.

1. We could quasi-automatically verify that all SQL-language functions 
have the correct search path (or even set it in initdb).

2. On things like unnest, which is a language element that we happen to 
implement as a function now, you don't have to worry about it one way or 
the other.

In a shell script, you'd usually set the path at the top instead of 
writing out the directories of every command.  It looks better (reason 
0), it's easier to analyze (e.g., lintian) (reason 1), and it avoids 
confusion with shell built-ins (reason 2).


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] Psql List Languages
Next
From: Robert Haas
Date:
Subject: Re: PQinitSSL broken in some use casesf