Re: Discussion: psql \et -> edit the trigger function - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Discussion: psql \et -> edit the trigger function
Date
Msg-id CAFj8pRBXiBuTeTDSsih1tA+c+UYAars2c_qAvp5=oPMTd_t0CA@mail.gmail.com
Whole thread Raw
In response to Re: Discussion: psql \et -> edit the trigger function  (Kirk Wolak <wolakk@gmail.com>)
List pgsql-hackers


st 10. 5. 2023 v 19:08 odesílatel Kirk Wolak <wolakk@gmail.com> napsal:
On Wed, May 10, 2023 at 12:20 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
Hi

st 10. 5. 2023 v 17:33 odesílatel Kirk Wolak <wolakk@gmail.com> napsal:
We already have
\ef
\ev

The use case here is simply that it saves me from:
\d <table>
[scroll through all the fields]
[often scroll right]
select function name
\ef [paste function name]

and tab completion is much narrower

When doing conversions and reviews all of this stuff has to be reviewed.
Oftentimes, renamed, touched.

I am 100% willing to write the code, docs, etc. but would appreciate feedback.

\et can be little bit confusing, because looks like editing trigger, not trigger function

what \eft triggername

?

Pavel, I am "torn" because of my OCD, I would expect 
\eft <TAB>
to list functions that RETURN TRIGGER as opposed to the level of indirection I was aiming for.

where
\et <TAB>
  Would specifically let me complete the Trigger_Name, but find the function

It makes me wonder, now if:
\etf 

Is better for this (edit trigger function... given the trigger name).
And as another poster suggested.  As we do the AUTOCOMPLETE for that, we could address it for:
\ef?

because:
\eft <TAB>
is valuable as well, and deserves to work just like all \ef? items

It seems like a logical way to break it down.   

This is a problem, and it isn't easy to find a design that is consistent and useful. Maybe Tom's proposal "\st" is best, although the "t" can be messy - it can be "t" like table or "t" like trigger or "t" like type.

Personally, I don't like editing DDL in psql or pgAdmin. In all my training I say "don't do it". But on second hand,  I agree so it can be handy for prototyping or for some playing.

I think implementing "\st triggername" can be a good start, and then we can continue in design later.

My comments:

* Maybe "\str" can be better than only "\st". Only "\st" can be confusing - minimally we use "t" like symbol for tables

* I think so arguments can be - tablename, triggername or [tablename triggername]

It can display more triggers than just one when specification is general or result is not uniq

Regards

Pavel







 
regards

Pavel

 

Kirk...

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Time delayed LR (WAS Re: logical replication restrictions)
Next
From: Peter Smith
Date:
Subject: pg_upgrade - typo in verbose log