| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Rod Taylor <rod(dot)taylor(at)gmail(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: FWD: Re: Updated backslash consistency patch |
| Date: | 2009-01-15 18:01:15 |
| Message-ID: | 8760.1232042475@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Rod Taylor <rod(dot)taylor(at)gmail(dot)com> writes:
> Right now pg_catalog sneaks its way onto the search_path for everybody. That
> is fine for execution but information listing like this should probably
> ignore those additions.
Actually, the single worst, most misleading, pernicious and dangerous
aspect of the currently committed behavior is exactly that it doesn't
work exactly like the search path. If I say "\df foo", it should tell
me about the same function(s) I would get from "select foo(...)".
As-is, it would tell me about a user-defined function even if that
function is masked by a similarly named system function. I don't
think that should *ever* happen. The converse is true if I have a
user function masking a system function (which is also possible, though
not with the default search path). So it's arguable that both 'S'
and the reverse are bad ideas.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-01-15 18:06:22 | Re: FWD: Re: Updated backslash consistency patch |
| Previous Message | Sam Mason | 2009-01-15 17:55:11 | Re: FWD: Re: Updated backslash consistency patch |