Re: Making tab-complete.c easier to maintain - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Making tab-complete.c easier to maintain
Date
Msg-id CAB7nPqSCekNhu67cM3GYqnrKyvM3SdXr97URbeA3BY7XoKwWJw@mail.gmail.com
Whole thread Raw
In response to Re: Making tab-complete.c easier to maintain  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Making tab-complete.c easier to maintain  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Dec 31, 2015 at 9:13 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Wed, Dec 30, 2015 at 11:21 PM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
>> Michael Paquier wrote:
>>
>>> OK, here are new patches.
>>> - 0001 switches a bunch of TailMatches to Matches. Do we want to care
>>> about the case where a schema is created following by a bunch of
>>> objects? I mean stuff like "CREATE SCHEMA hoge CREATE TABLE ..." where
>>> the current completion would work fine. The performance gains seem
>>> worth it compared to the number of people actually using it, the point
>>> has just not been raised yet.
>>
>> I'd rather have the completion work for that case than get a few
>> microseconds speedup.  As far as I recall, it's only four commands that
>> must retain the old coding.
>
> Fine for me this way.

So, here are the commands that still remain with TailMatches to cover
this case, per gram.y:
- CREATE TABLE
- CREATE INDEX
- CREATE VIEW
- GRANT
- CREATE TRIGGER
- CREATE SEQUENCE
New patches are attached.
Regards,
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: strange behaviour of psql \e command
Next
From: Amit Kapila
Date:
Subject: Re: Some 9.5beta2 backend processes not terminating properly?