2010/6/17 Greg Stark <gsst...@mit.edu>: > On Thu, Jun 17, 2010 at 4:08 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I actually wonder if we shouldn't automatically tag plpgsql functions >>> with the search_path in effect at the time of their creation (as if >>> the user had done ALTER FUNCTION ... SET search_path=...whatever the >>> current search path is...). >> >> That would be extremely expensive and not very backwards-compatible. >> In the case at hand, just writing "RETURN bar.bar();" would be the >> best-performing solution. >> > > I wonder if we should have a mode for plpgsql functions where all name > lookups are done at definition time So the bar() function would be > resolved to bar.bar() and stored that way permanently so that pg_dump > dumped the definition as bar.bar(). > > That would be probably just as good as setting the search path on the > function for most users and better for some. It would have the same > problem with dynamic sql that a lot of things have though.
+1 IMHO PG should dump the bar() function call as bar.bar() to be safe. Using fully qualified function name is what I did in my source code, to work around this problem. -- Jean-Baptiste Quenot -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
