Re: Documentation of psql's \df no longer matches reality

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Subject: Re: Documentation of psql's \df no longer matches reality
Date: 2023-08-02 02:36:01
Message-ID: CAKFQuwZ7v_vRPbaTwUpWZP=ZpV=2Osz-uPioC6NOx4TgR_g4aw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 2, 2023 at 3:34 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2023-08-02 02:40:04 Re: Adding a LogicalRepWorker type field
Previous Message Peter Smith 2023-08-02 02:31:56 Re: Adding a LogicalRepWorker type field