Tom Lane wrote:
Alvaro Herrera <alvhe...@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).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
