Re: Tab complete for CREATE OR REPLACE TRIGGER statement

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

regards, tom lane

In response to


Browse pgsql-hackers by date

  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?