From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Kirk Wolak <wolakk(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Discussion: psql \et <trigger_name> -> edit the trigger function |
Date: | 2023-05-11 05:26:50 |
Message-ID: | CAFj8pRBXiBuTeTDSsih1tA+c+UYAars2c_qAvp5=oPMTd_t0CA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
st 10. 5. 2023 v 19:08 odesílatel Kirk Wolak <wolakk(at)gmail(dot)com> napsal:
> On Wed, May 10, 2023 at 12:20 PM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
>> Hi
>>
>> st 10. 5. 2023 v 17:33 odesílatel Kirk Wolak <wolakk(at)gmail(dot)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...
>>>
>>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2023-05-11 05:41:20 | pg_upgrade - typo in verbose log |
Previous Message | Amit Kapila | 2023-05-11 05:04:44 | Re: Time delayed LR (WAS Re: logical replication restrictions) |