Re: [HACKERS] Making tab-complete.c easier to maintain

On 01/06/2016 01:13 AM, Michael Paquier wrote: On Wed, Jan 6, 2016 at 2:03 AM, Tom Lane wrote: I've pushed the second patch now. I made a few adjustments --- notably, I didn't like the way you'd implemented '*' wildcards, because they wouldn't have behaved very sanely in

Re: [HACKERS] Making tab-complete.c easier to maintain

I wrote: > Michael Paquier writes: >> 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. >

Re: [HACKERS] Making tab-complete.c easier to maintain

On Wed, Jan 6, 2016 at 2:03 AM, Tom Lane wrote: > I wrote: >> Michael Paquier writes: >>> So, here are the commands that still remain with TailMatches to cover >>> this case, per gram.y: >>> - CREATE TABLE >>> - CREATE INDEX >>> - CREATE VIEW >>> -

Re: [HACKERS] Making tab-complete.c easier to maintain

Michael Paquier writes: > 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. I've reviewed and

Re: [HACKERS] Making tab-complete.c easier to maintain

On Tue, Jan 5, 2016 at 10:13 AM, Tom Lane wrote: > Michael Paquier writes: >> 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

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Dec 31, 2015 at 9:13 AM, Michael Paquier wrote: > On Wed, Dec 30, 2015 at 11:21 PM, Alvaro Herrera > wrote: >> Michael Paquier wrote: >> >>> OK, here are new patches. >>> - 0001 switches a bunch of TailMatches to Matches. Do we want to

Re: [HACKERS] Making tab-complete.c easier to maintain

On Wed, Dec 30, 2015 at 11:21 PM, Alvaro Herrera 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

Re: [HACKERS] Making tab-complete.c easier to maintain

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

Re: [HACKERS] Making tab-complete.c easier to maintain

On Wed, Dec 30, 2015 at 9:14 AM, Michael Paquier wrote: > On Wed, Dec 30, 2015 at 6:26 AM, Thomas Munro wrote: >> I see that you changed INSERT and DELETE (but not UPDATE) to use >> MatchesN rather than TailMatchesN. Shouldn't these stay with >> TailMatchesN for the reason Tom gave above? > > Er,

Re: [HACKERS] Making tab-complete.c easier to maintain

Michael Paquier writes: >> On Sun, Dec 20, 2015 at 6:24 AM, Tom Lane wrote: >>> 1. I think it would be a good idea to convert the matching rules for >>> backslash commands too. To do that, we'd need to provide a case-sensitive >>> equivalent to

Re: [HACKERS] Making tab-complete.c easier to maintain

On Wed, Dec 30, 2015 at 1:21 AM, Tom Lane wrote: > This is because of the use of strncmp instead of plain strcmp > in most of the backslash matching rules, eg the above case is > covered by > > else if (strncmp(prev_wd, "\\df", strlen("\\df")) == 0) Ah, OK. The length

Re: [HACKERS] Making tab-complete.c easier to maintain

On Wed, Dec 30, 2015 at 6:26 AM, Thomas Munro wrote: > On Wed, Dec 30, 2015 at 3:14 AM, Michael Paquier > wrote: >> On Sun, Dec 20, 2015 at 8:08 AM, Michael Paquier >> wrote: >>> On Sun, Dec 20, 2015 at 6:24

Re: [HACKERS] Making tab-complete.c easier to maintain

On Wed, Dec 30, 2015 at 3:14 AM, Michael Paquier wrote: > On Sun, Dec 20, 2015 at 8:08 AM, Michael Paquier > wrote: >> On Sun, Dec 20, 2015 at 6:24 AM, Tom Lane wrote: >>> 2. I believe that a very large fraction of the

Re: [HACKERS] Making tab-complete.c easier to maintain

On Sun, Dec 20, 2015 at 8:08 AM, Michael Paquier wrote: > On Sun, Dec 20, 2015 at 6:24 AM, Tom Lane wrote: >> 1. I think it would be a good idea to convert the matching rules for >> backslash commands too. To do that, we'd need to provide a

Re: [HACKERS] Making tab-complete.c easier to maintain

On Sun, Dec 20, 2015 at 10:24 AM, Tom Lane wrote: > I've committed this now with a number of changes, many of them just > stylistic. Thanks! And thanks also to Michael, Kyotaro, Alvaro and Jeff. +1 for the suggested further improvements, which I will help out with where I

Re: [HACKERS] Making tab-complete.c easier to maintain

Michael Paquier writes: > On Sat, Dec 19, 2015 at 5:42 AM, Tom Lane wrote: >> 2. Why does MatchAnyExcept use "'" as the inversion flag, rather than >> say "!" or "~" ? Seems pretty random. > Actually, "'" is not that much a good idea, no? There

Re: [HACKERS] Making tab-complete.c easier to maintain

On Sun, Dec 20, 2015 at 6:24 AM, Tom Lane wrote: > 1. I think it would be a good idea to convert the matching rules for > backslash commands too. To do that, we'd need to provide a case-sensitive > equivalent to word_match and the matching macros. I think we'd also have > to

Re: [HACKERS] Making tab-complete.c easier to maintain

Michael Paquier writes: > On Sat, Dec 19, 2015 at 5:42 AM, Tom Lane wrote: >> 1. It seems inconsistent that all the new macros are named in CamelCase >> style, whereas there is still plenty of usage of the existing macros like >> COMPLETE_WITH_LIST.

Re: [HACKERS] Making tab-complete.c easier to maintain

I wrote: > 3. The HeadMatches macros are pretty iffy because they can only look back > nine words. I'm tempted to redesign get_previous_words so it just > tokenizes the whole line rather than having an arbitrary limitation. > (For that matter, it's long overdue for it to be able to deal with >

Re: [HACKERS] Making tab-complete.c easier to maintain

On Sat, Dec 19, 2015 at 5:42 AM, Tom Lane wrote: > Thomas Munro writes: >> [ tab-complete-macrology-v11.patch.gz ] > > A couple of stylistic reactions after looking through the patch for the > first time in a long time: > > 1. It seems

Re: [HACKERS] Making tab-complete.c easier to maintain

Michael Paquier writes: > OK, I am marking that as ready for committer. Let's see what happens next. I'll pick this up, as penance for not having done much in this commitfest. I think it's important to get it pushed quickly so that Thomas doesn't have to keep tracking

Re: [HACKERS] Making tab-complete.c easier to maintain

Thomas Munro writes: > [ tab-complete-macrology-v11.patch.gz ] A couple of stylistic reactions after looking through the patch for the first time in a long time: 1. It seems inconsistent that all the new macros are named in CamelCase style, whereas there is still

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Dec 17, 2015 at 7:24 PM, Michael Paquier wrote: > On Thu, Dec 17, 2015 at 3:06 PM, Kyotaro HORIGUCHI > wrote: >> At Mon, 14 Dec 2015 14:13:02 +0900, Michael Paquier >> wrote in >>

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Dec 17, 2015 at 6:04 PM, Thomas Munro wrote: > On Thu, Dec 17, 2015 at 7:24 PM, Michael Paquier > wrote: > Kyotaro's suggestion of using a macro NEG x to avoid complicating the > string constants seems good to me. But perhaps

Re: [HACKERS] Making tab-complete.c easier to maintain

Hello. Ok, I withdraw the minilang solution and I'll go on Thomas's way, which is still good to have. At Mon, 14 Dec 2015 14:13:02 +0900, Michael Paquier wrote in > On Mon, Dec 14, 2015 at 8:10 AM,

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Dec 17, 2015 at 3:06 PM, Kyotaro HORIGUCHI wrote: > At Mon, 14 Dec 2015 14:13:02 +0900, Michael Paquier > wrote in > >> On Mon, Dec 14, 2015 at 8:10 AM,

Re: [HACKERS] Making tab-complete.c easier to maintain

On Sun, Dec 13, 2015 at 1:08 AM, Michael Paquier wrote: > On Wed, Dec 9, 2015 at 8:17 PM, Thomas Munro wrote: >> Thanks for looking at this Michael. It's probably not much fun to >> review! Here is a new version with that bit removed. More responses >> inline below.

Re: [HACKERS] Making tab-complete.c easier to maintain

On Mon, Dec 14, 2015 at 8:10 AM, Thomas Munro wrote: > I've also add (very) primitive negative pattern support and used it in > 5 places. Improvement? Examples: > > /* ALTER TABLE xxx RENAME yyy */ > - else if (TailMatches5("ALTER", "TABLE",

Re: [HACKERS] Making tab-complete.c easier to maintain

On Sat, Dec 12, 2015 at 12:00 AM, Tom Lane wrote: > Greg Stark writes: >> So I don't think it makes sense to hold up improvements today hoping >> for something like this. > > Yeah, it's certainly a wishlist item rather than something that should > block

Re: [HACKERS] Making tab-complete.c easier to maintain

On Wed, Dec 9, 2015 at 8:17 PM, Thomas Munro wrote: > Thanks for looking at this Michael. It's probably not much fun to > review! Here is a new version with that bit removed. More responses > inline below. Could this patch be rebased? There are now conflicts with 8b469bd7 and it does not apply

Re: [HACKERS] Making tab-complete.c easier to maintain

On Fri, Dec 11, 2015 at 8:12 AM, Michael Paquier wrote: > Also, if > we prioritize a dynamically generated tab completion using gram.y, so > be it and let's reject both patches then... Fwiw I poked at the bison output to see if it would be possible to do. I think it's

Re: [HACKERS] Making tab-complete.c easier to maintain

Greg Stark writes: > Fwiw I poked at the bison output to see if it would be possible to do. > I think it's theoretically possible but a huge project and would > create dependencies on bison internals that we would be unlikelly to > accept. That's the impression I got when I looked

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Dec 10, 2015 at 5:38 PM, Kyotaro HORIGUCHI wrote: > I'm unhappy with context matching using previous_words in two > points. Current code needs human-readable comments describing > almost all matchings. It is hard to maintain and some of them > actually are

Re: [HACKERS] Making tab-complete.c easier to maintain

Hello, At Wed, 9 Dec 2015 10:31:06 -0800, David Fetter wrote in <20151209183106.gc10...@fetter.org> > On Wed, Dec 09, 2015 at 03:49:20PM +, Greg Stark wrote: > > On Wed, Dec 9, 2015 at 2:27 PM, David Fetter wrote: > > > Agreed that the "whole new

Re: [HACKERS] Making tab-complete.c easier to maintain

On Mon, Dec 7, 2015 at 8:41 PM, Michael Paquier wrote: > On Tue, Nov 17, 2015 at 12:19 AM, Alvaro Herrera > wrote: >> Thomas Munro wrote: >>> New version attached, merging recent changes. >> >> I wonder about the TailMatches and Matches macros

Re: [HACKERS] Making tab-complete.c easier to maintain

On Wed, Dec 9, 2015 at 8:17 PM, Thomas Munro wrote: > On Mon, Dec 7, 2015 at 8:41 PM, Michael Paquier > wrote: >> On Tue, Nov 17, 2015 at 12:19 AM, Alvaro Herrera >> wrote: >>> Thomas Munro wrote: New

Re: [HACKERS] Making tab-complete.c easier to maintain

On Wed, Dec 09, 2015 at 08:49:22PM +0900, Michael Paquier wrote: > On Wed, Dec 9, 2015 at 8:17 PM, Thomas Munro > wrote: > > On Mon, Dec 7, 2015 at 8:41 PM, Michael Paquier > > wrote: > >> On Tue, Nov 17, 2015 at 12:19 AM, Alvaro Herrera

Re: [HACKERS] Making tab-complete.c easier to maintain

On Wed, Dec 9, 2015 at 2:27 PM, David Fetter wrote: > Agreed that the "whole new language" aspect seems like way too big a > hammer, given what it actually does. Which would be easier to update when things change? Which would be possible to automatically generate from gram.y?

Re: [HACKERS] Making tab-complete.c easier to maintain

On Wed, Dec 09, 2015 at 03:49:20PM +, Greg Stark wrote: > On Wed, Dec 9, 2015 at 2:27 PM, David Fetter wrote: > > Agreed that the "whole new language" aspect seems like way too big a > > hammer, given what it actually does. > > Which would be easier to update when things

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Dec 10, 2015 at 12:49 AM, Greg Stark wrote: > On Wed, Dec 9, 2015 at 2:27 PM, David Fetter wrote: >> Agreed that the "whole new language" aspect seems like way too big a >> hammer, given what it actually does. > > Which would be easier to update when

Re: [HACKERS] Making tab-complete.c easier to maintain

Thank you for looking on this and the comment. At Mon, 7 Dec 2015 15:00:32 +0900, Michael Paquier wrote in

Re: [HACKERS] Making tab-complete.c easier to maintain

On Tue, Dec 8, 2015 at 6:31 PM, Kyotaro HORIGUCHI wrote: > > Thank you for looking on this and the comment. > > At Mon, 7 Dec 2015 15:00:32 +0900, Michael Paquier > wrote in >

Re: [HACKERS] Making tab-complete.c easier to maintain

Hello, At Tue, 8 Dec 2015 20:50:39 +0900, Michael Paquier wrote in

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Nov 26, 2015 at 2:45 PM, Kyotaro HORIGUCHI wrote: > What do you think about this solution? This patch fails to compile on OSX: Undefined symbols for architecture x86_64: "_ExceptionalCondition", referenced from: _pg_regexec in regexec.o

Re: [HACKERS] Making tab-complete.c easier to maintain

On Tue, Nov 17, 2015 at 12:19 AM, Alvaro Herrera wrote: > Thomas Munro wrote: >> New version attached, merging recent changes. > > I wonder about the TailMatches and Matches macros --- wouldn't it be > better to have a single one, renaming TailMatches to Matches and >

Re: [HACKERS] Making tab-complete.c easier to maintain

Hello, I tried to implement the mini-language, which is a simplified reglar expression for this specific use. As a ultra-POC, the attached patch has very ad-hoc preprocess function and does on-the-fly preprocessing, compilation then execution of regular expression. And it is applied to only the

Re: [HACKERS] Making tab-complete.c easier to maintain

Thomas Munro wrote: > New version attached, merging recent changes. I wonder about the TailMatches and Matches macros --- wouldn't it be better to have a single one, renaming TailMatches to Matches and replacing the current Matches() with an initial token that corresponds to anchoring to start of

Re: [HACKERS] Making tab-complete.c easier to maintain

Kyotaro HORIGUCHI wrote: > Auto-generating from grammer should be the ultimate solution but > I don't think it will be available. But still I found that the > word-splitting-then-match-word-by-word-for-each-matching is > terriblly unmaintainable and poorly capable. So, how about > regular

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Nov 12, 2015 at 1:16 PM, Kyotaro HORIGUCHI wrote: > 1. 0001-Allow-regex-module-to-be-used-outside-server.patch > > This small change makes pg_regex possible to be used in > frontend. This is generic enough to live in src/common, then psql would directly reuse it using lpgcommon. > 2.

Re: [HACKERS] Making tab-complete.c easier to maintain

Hello, thank you for many valuable opinions. I am convinced that bare regular expressions cannot be applied here:) At Mon, 16 Nov 2015 18:59:06 +1300, Thomas Munro wrote in

Re: [HACKERS] Making tab-complete.c easier to maintain

Hello, At Mon, 16 Nov 2015 12:19:23 -0300, Alvaro Herrera wrote in <20151116151923.GX614468@alvherre.pgsql> > Thomas Munro wrote: > > New version attached, merging recent changes. > > I wonder about the TailMatches and Matches macros --- wouldn't it be > better to

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Nov 12, 2015 at 5:16 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello. How about regular expressions? > > I've been thinking of better mechanism for tab-compltion for > these days since I found some bugs in it. > > At Fri, 23 Oct 2015 14:50:58 -0300, Alvaro Herrera

Re: [HACKERS] Making tab-complete.c easier to maintain

New version attached, merging recent changes. -- Thomas Munro http://www.enterprisedb.com tab-complete-v8.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Making tab-complete.c easier to maintain

On Sat, Oct 24, 2015 at 6:19 AM, Jeff Janes wrote: > On Sun, Oct 18, 2015 at 9:12 PM, Thomas Munro > wrote: >> Thanks for taking a look at this! The word count returned by >> get_previous_words was incorrect. Here is a corrected version. > >

Re: [HACKERS] Making tab-complete.c easier to maintain

On Fri, Oct 23, 2015 at 02:09:43AM +0200, Andres Freund wrote: > On 2015-10-22 16:26:10 -0700, David Fetter wrote: > > To be affective negatively by libreadline's viral license, an entity > > would need to fork the psql client in proprietary ways that they did > > not wish not to make available to

Re: [HACKERS] Making tab-complete.c easier to maintain

On Fri, Oct 23, 2015 at 11:16 AM, David Fetter wrote: > Proprietary, secret changes to the back end, sure, but the client? > The most recent example I recall of that is Netezza, and I suspect > that they just couldn't be bothered to publish the changes they made. > At that time,

Re: [HACKERS] Making tab-complete.c easier to maintain

David Fetter writes: > Is it really on us as a community to go long distances out of our way > to assuage the baseless[1] paranoia of people who are by and large not > part of our community? While I personally don't care that much about the proprietary-psql-variant scenario, I

Re: [HACKERS] Making tab-complete.c easier to maintain

Jeff Janes wrote: > For the bigger picture, I don't think we should not apply this patch simply > because there is something even better we might theoretically do at some > point in the future. Agreed. > Having used it a little bit, I do agree with Robert > that it is not a gigantic improvement

Re: [HACKERS] Making tab-complete.c easier to maintain

On Sun, Oct 18, 2015 at 9:12 PM, Thomas Munro wrote: > > Thanks for taking a look at this! The word count returned by > get_previous_words was incorrect. Here is a corrected version. > I haven't looked at v6 yet, but in v5: "set work_mem TO" completes to

Re: [HACKERS] Making tab-complete.c easier to maintain

On Fri, Oct 23, 2015 at 12:15:01PM -0400, Robert Haas wrote: > On Fri, Oct 23, 2015 at 11:16 AM, David Fetter wrote: > > Proprietary, secret changes to the back end, sure, but the client? > > The most recent example I recall of that is Netezza, and I suspect > > that they just

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Oct 22, 2015 at 10:36 PM, Tom Lane wrote: > What I would like is to find a way to auto-generate basically this entire > file from gram.y. That would imply going over to something at least > somewhat parser-based, instead of the current way that is more or less >

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Oct 22, 2015 at 02:36:53PM -0700, Tom Lane wrote: > Robert Haas writes: > > On Wed, Oct 21, 2015 at 8:54 PM, Thomas Munro > > wrote: > >> (Apologies for sending so many versions. tab-complete.c keeps moving > >> and I want to keep a

Re: [HACKERS] Making tab-complete.c easier to maintain

Tom Lane wrote: > What I would like is to find a way to auto-generate basically this entire > file from gram.y. That would imply going over to something at least > somewhat parser-based, instead of the current way that is more or less > totally ad-hoc. That would be a very good thing though,

Re: [HACKERS] Making tab-complete.c easier to maintain

On Wed, Oct 21, 2015 at 8:54 PM, Thomas Munro wrote: > Here is a new version merging the recent CREATE EXTENSION ... VERSION > patch from master. > > (Apologies for sending so many versions. tab-complete.c keeps moving > and I want to keep a version that applies on

Re: [HACKERS] Making tab-complete.c easier to maintain

Robert Haas writes: > On Wed, Oct 21, 2015 at 8:54 PM, Thomas Munro > wrote: >> (Apologies for sending so many versions. tab-complete.c keeps moving >> and I want to keep a version that applies on top of master out there, >> for anyone

Re: [HACKERS] Making tab-complete.c easier to maintain

David Fetter writes: > On Thu, Oct 22, 2015 at 02:36:53PM -0700, Tom Lane wrote: >> I have no very good idea how to do that, though. Bison does have a >> notion of which symbols are possible as the next symbol at any given >> parse point, but it doesn't really make that

Re: [HACKERS] Making tab-complete.c easier to maintain

David Fetter writes: > On Thu, Oct 22, 2015 at 04:05:06PM -0700, Tom Lane wrote: >> Given the license issues around GNU readline, requiring it seems like >> probably a non-starter. > I should have made this more clear. I am not an IP attorney and don't > play one on TV, but

Re: [HACKERS] Making tab-complete.c easier to maintain

On 2015-10-22 16:26:10 -0700, David Fetter wrote: > To be affective negatively by libreadline's viral license, an entity > would need to fork the psql client in proprietary ways that they did > not wish not to make available to end users, at the same time linking > in libreadline. > Maybe I'm

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Oct 22, 2015 at 8:09 PM, Andres Freund wrote: > On 2015-10-22 16:26:10 -0700, David Fetter wrote: >> To be affective negatively by libreadline's viral license, an entity >> would need to fork the psql client in proprietary ways that they did >> not wish not to make

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Oct 22, 2015 at 7:05 PM, Tom Lane wrote: > I think it's already true that the previous lines of the query buffer > are stashed somewhere that psql knows about, ​Just skimming but:​ ​""" ​\p or \print Print the current query buffer to the standard output. """

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Oct 22, 2015 at 04:05:06PM -0700, Tom Lane wrote: > David Fetter writes: > > On Thu, Oct 22, 2015 at 02:36:53PM -0700, Tom Lane wrote: > >> I have no very good idea how to do that, though. Bison does have a > >> notion of which symbols are possible as the next symbol at

Re: [HACKERS] Making tab-complete.c easier to maintain

* Tom Lane (t...@sss.pgh.pa.us) wrote: > David Fetter writes: > > On Thu, Oct 22, 2015 at 04:05:06PM -0700, Tom Lane wrote: > >> Given the license issues around GNU readline, requiring it seems like > >> probably a non-starter. > > > I should have made this more clear. I am

Re: [HACKERS] Making tab-complete.c easier to maintain

Stephen Frost wrote: > The issue for Debian, at least, isn't really about libreadline or > libedit, it's about the GPL and the OpenSSL license. From the Debian > perspective, if we were able to build with GNUTLS or another SSL library > other than OpenSSL (which I know we've made some progress

Re: [HACKERS] Making tab-complete.c easier to maintain

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > > The issue for Debian, at least, isn't really about libreadline or > > libedit, it's about the GPL and the OpenSSL license. From the Debian > > perspective, if we were able to build with GNUTLS or another SSL library

Re: [HACKERS] Making tab-complete.c easier to maintain

Here is a new version merging the recent CREATE EXTENSION ... VERSION patch from master. (Apologies for sending so many versions. tab-complete.c keeps moving and I want to keep a version that applies on top of master out there, for anyone interested in looking at this. As long as no one objects

Re: [HACKERS] Making tab-complete.c easier to maintain

Hi Here is a new version merging recent changes. -- Thomas Munro http://www.enterprisedb.com tab-complete-macrology-v4.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Making tab-complete.c easier to maintain

On Sun, Oct 18, 2015 at 5:31 PM, Thomas Munro wrote: > Hi > > Here is a new version merging recent changes. > For reasons I do not understand, "SET work_mem " does not complete with "TO". But if I change: else if (Matches2("SET", MatchAny)) to: else if

Re: [HACKERS] Making tab-complete.c easier to maintain

On Mon, Oct 19, 2015 at 4:58 PM, Jeff Janes wrote: > On Sun, Oct 18, 2015 at 5:31 PM, Thomas Munro > wrote: >> >> Hi >> >> Here is a new version merging recent changes. > > > For reasons I do not understand, "SET work_mem " does not complete

Re: [HACKERS] Making tab-complete.c easier to maintain

On Tue, Sep 8, 2015 at 1:56 AM, Alvaro Herrera wrote: > Thomas Munro wrote: > > > Thanks, good point. Here's a version that uses NULL via a macro ANY. > > Aside from a few corrections it also now distinguishes between > > TAIL_MATCHESn (common) and MATCHESn (rarely

Re: [HACKERS] Making tab-complete.c easier to maintain

Thomas Munro wrote: > Thanks, good point. Here's a version that uses NULL via a macro ANY. > Aside from a few corrections it also now distinguishes between > TAIL_MATCHESn (common) and MATCHESn (rarely used for now), for example: This looks pretty neat -- 100x neater than what we have, at any

Re: [HACKERS] Making tab-complete.c easier to maintain

Thomas Munro writes: > See attached a proof-of-concept patch. It reduces the size of > tab-complete.c by a bit over a thousand lines. I realise that changing so > many lines just to refactor code may may be a difficult sell! But I think > this would make it