Robert Haas <robertmhaas@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 functionsSchema | 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 functionsSchema | 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