Re: Tab complete for CREATE OR REPLACE TRIGGER statement - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Tab complete for CREATE OR REPLACE TRIGGER statement
Date
Msg-id 987986.1605714573@sss.pgh.pa.us
Whole thread Raw
In response to Re: Tab complete for CREATE OR REPLACE TRIGGER statement  (Tels <nospam-pg-abuse@bloodgate.com>)
Responses Re: Tab complete for CREATE OR REPLACE TRIGGER statement  (Tels <nospam-pg-abuse@bloodgate.com>)
List pgsql-hackers
Tels <nospam-pg-abuse@bloodgate.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



pgsql-hackers by date:

Previous
From: Pavel Borisov
Date:
Subject: Re: Is postgres ready for 2038?
Next
From: Dmitry Dolgov
Date:
Subject: Re: pg_stat_statements and "IN" conditions