From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | nospam-pg-abuse(at)bloodgate(dot)com |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, "Shinoda, Noriyoshi (PN Japan FSI)" <noriyoshi(dot)shinoda(at)hpe(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Tab complete for CREATE OR REPLACE TRIGGER statement |
Date: | 2020-11-18 15:49:33 |
Message-ID: | 987986.1605714573@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tels <nospam-pg-abuse(at)bloodgate(dot)com> writes:
> On 2020-11-18 06:06, Michael Paquier wrote:
>> On Mon, Nov 16, 2020 at 10:14:10PM -0500, Tom Lane wrote:
>>> Agreed, I'm not trying to block this patch. Just wishing
>>> there were a better way.
> To me the code looks like a prime candidate for "data-driven"
> refactoring.
> It should be redone as generic code that reads a table of rules with
> params and then checks and applies each. Thus the repetitive code would
> be replaced by a bit more generic code and a lot of code-free data.
In the past I've looked into whether the rules could be autogenerated
from the backend's grammar. It did not look very promising though.
The grammar isn't really factorized appropriately -- for instance,
tab-complete has a lot of knowledge about which kinds of objects can
be named in particular places, while the Bison productions only know
that's a "name". Still, the precedent of ECPG suggests it might be
possible to process the grammar rules somehow to get to a useful
result.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2020-11-18 16:04:32 | Re: pg_stat_statements and "IN" conditions |
Previous Message | Pavel Borisov | 2020-11-18 15:27:20 | Re: Is postgres ready for 2038? |