Re: Discussion: psql \et <trigger_name> -> edit the trigger function

On Wed, May 10, 2023 at 1:33 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I wrote:
> > Hmm, I wonder how useful that's really going to be, considering
> > that trigger names aren't unique across tables. Wouldn't it
> > need to be more like "\et table-name trigger-name"?
>
> Different line of thought: \et seems awfully single-purpose.
> Perhaps we should think more of "\st table-name trigger-name"
> (show trigger), which perhaps could print something along the
> lines of
>
> CREATE TRIGGER after_ins_stmt_trig AFTER INSERT ON main_table
> FOR EACH STATEMENT EXECUTE FUNCTION trigger_func('after_ins_stmt');
>
> CREATE FUNCTION public.trigger_func()
> RETURNS trigger
> ... the rest like \sf for the trigger function
>
> If you indeed want to edit the function, it's a quick copy-and-paste
> from here. But if you just want to see the trigger definition,
> this is more wieldy than looking at the whole "\d table-name"
> output. Also we have less of an overloading problem with the
> command name.
>

I agree that the argument for \et or \etf fails. Simply on the one to many
issues.
And I agree that a more consistent approach is best.

Having just cleaned up 158 Triggers/Trigger Functions... Just having \eft
<TAB> work would be nice.

Which would solve my problem of quickly getting the tables triggers and
reviewing the code.

I like the idea of adding to the \s* options. As in "show".
but the "t" is very common (table, trigger, type). I think \st \str \sty
could work, but this is the first place where we would be doing this?

Honestly I think \st is "missing", especially to throw something in
dbfiddle or another tool.

And if we drop "trigger" from this, then \st and \sT where T would be for
Types as elsewhere.

Now that feels more consistent?

So, currently thinking:
1) lets get \ef? <TAB> working
2) Discuss: \st \sT for outputting Table and Type Creation DDL...

Something is telling me that #2 (\st) might be a can of worms, since it
seems so obviously "missing"?

>
> regards, tom lane
>

I appreciate the feedback!