Re: Documentation of psql's \df no longer matches reality
От | David G. Johnston |
---|---|
Тема | Re: Documentation of psql's \df no longer matches reality |
Дата | |
Msg-id | CAKFQuwZ7v_vRPbaTwUpWZP=ZpV=2Osz-uPioC6NOx4TgR_g4aw@mail.gmail.com обсуждение исходный текст |
Ответ на | Documentation of psql's \df no longer matches reality (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, Mar 2, 2023 at 3:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
It seems like we should either restore "trigger" as its own
type classification, or remove it from the list of properties
you can filter on, or adjust the docs to describe "t" as a
special filter condition. I'm kind of inclined to the second
option, because treating trigger as a different prokind sure
seems like a wart. But back in 2009 people thought that was
a good idea; what is our opinion now?
Personally, I'd go for option 1, bring back the formal concept of a trigger function to this view. Admit the mistake and back-patch so we are consistent again.
Or, to improve things, " \df func_name - trigger " should be made to provide a pattern filter on the output type, in which case people could then filter on any type they want, not just trigger. Incorporating set-returning functions into such a filtering mechanism would be a bonus worth striving for.
Between choices 2 and 3 above I'd go with 3 before 2. I can imagine the change to label the output of \dft as "func" would easily go unnoticed but removing the existing filtering feature seems likely to draw valid complaints. If we had the more powerful alternative described above to replace it with maybe I'd go for 2. Absent that it is a special case wart necessitated by the lack of being able to readily specify the return type filter in a manner similar to the existing input type filtering.
David J.
В списке pgsql-hackers по дате отправления: