Robert Haas <robertmh...@gmail.com> writes: > I think you should reconsider your non-buying of that argument. That > would be really, really annoying for me. Most of the time I want to > look at a user object. But every now and then I want to look at a > system object.
I still think that this argument is fundamentally misguided, at least with respect to the case where a pattern is given. If I say "\df sin" I should see the definition of sin(). I do not care in the slightest whether it's a system or user function. This behavior (seen in HEAD) is absolutely bogus: regression=# select sin(0.5); sin ------------------- 0.479425538604203 (1 row) regression=# \df sin List of functions Schema | Name | Result data type | Argument data types --------+------+------------------+--------------------- (0 rows) But it gets worse: regression=# create function sin(float8) returns float8 as regression-# 'select $1 + 1' language sql; CREATE FUNCTION regression=# select sin(0.5); sin ------------------- 0.479425538604203 -- user might be expecting 1.5 here (1 row) regression=# \df sin List of functions Schema | Name | Result data type | Argument data types --------+------+------------------+--------------------- (0 rows) Now I *have* a user function named sin(), it's not getting called (which might surprise me if I didn't know there was a conflicting system function) and \df doesn't show me either one. I actually was expecting the above example to show me the user function, which I was then going to rant about being a lie. But the actual behavior is even worse than that. There is not anything that is not broken about HEAD's behavior, and the sooner we admit that the sooner we can get to a fix. Slicing the categorization more finely or in different ways is not going to improve matters: the concept that there is a categorization that will make it hide requested objects is wrong to begin with. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers