Re: [HACKERS] Possible fix for occasional failures on castoroides etc
On 2014-05-03 13:25:32 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2012-09-17 08:23:01 -0400, Dave Page wrote: > >> I've added MAX_CONNECTIONS=5 to both Castoroides and Protosciurus. > > > I've just noticed (while checking whether backporting 4c8aa8b5aea caused > > problems) that this doesn't seem to have fixed the issue. One further > > thing to try would be to try whether tcp connections don't have the same > > problem. > > I did some googling on this, and found out that people have seen identical > behavior on Solaris with mysql and other products, so at least we're not > alone. Yea, I found a couple report of that as well. > Googling also reminded me that we could have a look at the source > (duh), which is still available from hg.openindiana.org. I didn't get that far ;) I think we should try whether the problem disappears if tcp connections are used. That ought to be much more heavily used in the real world. Thus less likely to be buggy. While It's not documented as such, passing --host=localhost to pg_regress seems to have the desired effect. Dave, could you make your animal specify that? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Possible fix for occasional failures on castoroides etc
I wrote: > Unfortunately, it seems the Solaris implementors didn't read Stevens, > because it looks to me like they *do* return ECONNREFUSED on accept queue > overflow. Still, it's hard to see how that would be the issue if we're > still seeing this failure with only five clients. Also, after further inspection of the source code, it appears to me that the kernel's limit on accept queue length is hard-wired at 4096 in Solaris. So there's basically no way that we're hitting that limit in the regression tests, and the MAX_CONNECTIONS configuration is irrelevant. We seem to be left with the race condition theory. In that connection, this comment in /usr/src/uts/common/io/tl.c is interesting: * The T_CONN_CON is generated when processing the T_CONN_REQ i.e. before * a T_CONN_RES is received from the acceptor. This means that a socket * connect will complete before the peer has called accept. I'm not sure that explains anything of value, but it's probably unlike any other implementation, which makes it perhaps relevant. It implies that this is totally unrelated to any server-side behavior; so if it's possible for us to work around it at all, we'd have to do so client-side. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pgindent run
I am planning to run pgindent in a few days to prepare for beta. Does anyone have major patches that you are planning to apply soon? If so, I can delay pgindent until you are done. This run will also have a tabs-in-comments removal phase which will also be run on supported back branches. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Possible fix for occasional failures on castoroides etc
Andres Freund writes: > On 2012-09-17 08:23:01 -0400, Dave Page wrote: >> I've added MAX_CONNECTIONS=5 to both Castoroides and Protosciurus. > I've just noticed (while checking whether backporting 4c8aa8b5aea caused > problems) that this doesn't seem to have fixed the issue. One further > thing to try would be to try whether tcp connections don't have the same > problem. I did some googling on this, and found out that people have seen identical behavior on Solaris with mysql and other products, so at least we're not alone. Googling also reminded me that we could have a look at the source (duh), which is still available from hg.openindiana.org. I poked around a bit and more or less confirmed the theory mentioned here: https://www.varnish-cache.org/trac/ticket/865 That is, Solaris' unix-sockets code will generate ECONNREFUSED if it finds that the socket is not connected and not waiting for a connection *and* there is no saved error code. One example is: if (so->so_error != 0) return (sogeterr(so, B_TRUE)); /* * Under normal circumstances, so_error should contain an error * in case the connect failed. However, it is possible for another * thread to come in a consume the error, so generate a sensible * error in that case. */ if ((so->so_state & SS_ISCONNECTED) == 0) return (ECONNREFUSED); Now, I can't imagine where the "other thread" hypothesized in this comment could be, so what I'm thinking is that maybe there's a bug somewhere that drops the connection attempt without setting any error in so_error; or maybe there's a race condition that releases the waiting client before so_error is set. But that still leaves the question of why the connection attempt is getting dropped at all. BTW, I also found no less an authority than W. Richard Stevens saying that my theory that this could happen from accept queue overflow was wrong, at least in a sane implementation: https://groups.google.com/forum/#!topic/comp.unix.solaris/e8QxFyXxr84 : >- there are too many outstanding connections that haven't : > been accepted yet (perhaps you can up the second parameter : > to listen) : : No. When the pending connection queue is filled, TCP ignores an : arriving SYN, it does not respond with an RST. This is a soft error : (a busy server) and by ignoring it, TCP forces the client to retransmit : the SYN, hopefully finding a less busy server at some time in the future. : For additional details and an example, check out pp. 257-260 of my "TCP/IP : Illustrated" (Addison-Wesley, 1994). : : Rich Stevens Unfortunately, it seems the Solaris implementors didn't read Stevens, because it looks to me like they *do* return ECONNREFUSED on accept queue overflow. Still, it's hard to see how that would be the issue if we're still seeing this failure with only five clients. There are just not that many references to ECONNREFUSED in the portions of the Solaris source tree that look like they could be related to Unix sockets, so it's hard to come up with more theories than this. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sending out a request for more buildfarm animals?
On 05/03/2014 12:42 PM, Tomas Vondra wrote: On 3.5.2014 03:07, Noah Misch wrote: More coverage of non-gcc compilers would be an asset to the buildfarm. Does that include non-gcc compilers on Linux/x86 platforms? Magpie is pretty much dedicated to the buildfarm, and it's pretty much doing nothing most of the time, so running the tests with other compilers (llvm/ic/...) would be just fine. Not sure how to do that, though. Should I run the tests with multiple configurations, or should we have one animal for each config? No, don't run with multiple configs. That makes it much harder to see where problems come from. One animal per config, please. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sending out a request for more buildfarm animals?
Tomas Vondra writes: > Magpie is pretty much dedicated to the buildfarm, and it's pretty much > doing nothing most of the time, so running the tests with other > compilers (llvm/ic/...) would be just fine. Not sure how to do that, > though. Should I run the tests with multiple configurations, or should > we have one animal for each config? I believe the intent is one animal name per configuration. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sending out a request for more buildfarm animals?
On 3.5.2014 03:07, Noah Misch wrote: > More coverage of non-gcc compilers would be an asset to the buildfarm. Does that include non-gcc compilers on Linux/x86 platforms? Magpie is pretty much dedicated to the buildfarm, and it's pretty much doing nothing most of the time, so running the tests with other compilers (llvm/ic/...) would be just fine. Not sure how to do that, though. Should I run the tests with multiple configurations, or should we have one animal for each config? Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sending out a request for more buildfarm animals?
On Sat, May 03, 2014 at 10:09:56AM +0200, Andres Freund wrote: > On 2014-05-02 21:07:55 -0400, Noah Misch wrote: > > +1 for sending a call for help to -announce. I agree with your importance > > estimates, particularly on the OS side. -1 for making code-level changes to > > "desupport" a platform based on the lack of a buildfarm member, though I > > don't > > mind documentation/advocacy changes on that basis. > > I was thinking of changing > http://www.postgresql.org/docs/devel/static/supported-platforms.html to > list untested platforms similar to the way M32R and VAX are > documented. I.e. code exists, but we have no clue whether it works. Sounds perfect. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Possible fix for occasional failures on castoroides etc
On 2012-09-17 08:23:01 -0400, Dave Page wrote: > On Sun, Sep 16, 2012 at 12:44 PM, Andrew Dunstan wrote: > > > > On 09/16/2012 12:04 PM, Tom Lane wrote: > >> > >> It's annoying that the buildfarm animals running on older versions of > >> Solaris randomly fail with "Connection refused" errors, such as in > >> today's example: > >> > >> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=castoroides&dt=2012-09-15%2015%3A42%3A52 > >> > >> I believe what's probably happening there is that the kernel has a small > >> hard-wired limit on the length of the postmaster's accept queue, and you > >> get this failure if too many connection attempts arrive faster than the > >> postmaster can service them. If that theory is correct, we could > >> probably prevent these failures by reducing the number of tests run in > >> parallel, which could be done by adding say > >> MAX_CONNECTIONS=5 > >> to the environment in which the regression tests run. I'm not sure > >> though if that's "build_env" or some other setting for the buildfarm > >> script --- Andrew? > >> > >> > > > > > > > > Yes, in the build_env section of the config file. > > > > It's in the distributed sample config file, commented out. > > I've added MAX_CONNECTIONS=5 to both Castoroides and Protosciurus. I've just noticed (while checking whether backporting 4c8aa8b5aea caused problems) that this doesn't seem to have fixed the issue. One further thing to try would be to try whether tcp connections don't have the same problem. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] need of anonymous record
On 05/03/2014 09:55 AM, Peter Krauss wrote: My notion of "anonymous record", and the need of this kind of "higher-order type", are discussed in the links below, http://stackoverflow.com/q/23439240 "Functions can not to /return individual items of a record/" http://stackoverflow.com/q/21246201 "PostgreSQL v9.X have real '/array of record/' ? The first question is about performance: "/returns table/" have the same performance than "/returns record/"?? If "yes", the /record/ datatype is somewhat outdated? Quite apart from other considerations such as the clear lack of understanding of semantics here, I at least am not going to follow threads to stackoverflow. If you want to discuss the actual or desired semantics of Postgres, the proper place is the Postgres mailing lists. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] need of anonymous record
Peter Padua Krauss wrote > The first question is about performance: "*returns table*" have the same > performance than "*returns record*"?? > If "yes", the *record* datatype is somewhat outdated? Table defines the possibility to return a set while record can only ever return a single value; so likely the set version is less performant but regardless they have different semantics. > I am new here, I do not know how, but I'm available to help... Can a > future > version of PostgreSQL implement some solution? Craig's reply in the array post explained the reality quite well. SQL is strongly typed so while some improvement on the use of anonymous record types is possible the SQL way of doing things would be to CREATE TYPE. Hstore and JSON provides an alternative means to define a column in a dynamic way. It is unlikely that records types would ever be altered for dynamic member access given that these types exist. But it is not impossible given a good implementation. The one benefit is that current attempts give errors so making it work only has to avoid performance regressions and not screw up the parser. As Craig said: how much does this bother you? If you cannot code C yourself are you willing to pay someone to implement this feature? The cost-benefit analysis suggests this particular need is a poor area to invest resources in. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/need-of-anonymous-record-tp5802301p5802303.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sending out a request for more buildfarm animals?
It's a POWER 7 machine. On 3. Mai 2014 10:31:34 MESZ, Dave Page wrote: >Hamid@EDB; Can you please have someone configure anole to build git >head as well as the other branches? Thanks. > >Andres, Andrew; I think the only other gap EDB could fill at the >moment is RHEL6 on Power7 (though we do have a couple of Power8 boxes >on order that should be here pretty soon). Dotterel is building some >branches (including head). I'm not sure what generation of Power CPU >that box has. Bernd? > >On Fri, May 2, 2014 at 4:04 PM, Andres Freund >wrote: >> Hi, >> >> There's pretty little coverage of non mainstream platforms/compilers >in >> the buildfarm atm. Maybe we should send an email on -announce asking >for >> new ones? >> There's no coverage for OS-wise; >> * AIX (at all) >> * HP-UX (for master at least) >> (* Tru64) >> (* UnixWare) >> >> Architecture wise there's no coverage for: >> * some ARM architecture varians >> * mips >> * s390/x >> * sparc 32bit >> (* s390) >> (* alpha) >> (* mipsel) >> (* M68K) >> >> A couple of those aren't that important (my opinion indicated by ()), >> but the other ones really should be covered or desupported. >> >> Greetings, >> >> Andres Freund >> >> -- >> Andres Freund http://www.2ndQuadrant.com/ >> PostgreSQL Development, 24x7 Support, Training & Services > > > >-- >Dave Page >Chief Architect, Tools & Installers >EnterpriseDB: http://www.enterprisedb.com >The Enterprise PostgreSQL Company > >Blog: http://pgsnake.blogspot.com >Twitter: @pgsnake -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
[HACKERS] need of anonymous record
My notion of "anonymous record", and the need of this kind of "higher-order type", are discussed in the links below, http://stackoverflow.com/q/23439240 "Functions can not to *return individual items of a record*" http://stackoverflow.com/q/21246201 "PostgreSQL v9.X have real '*array of record*' ? The first question is about performance: "*returns table*" have the same performance than "*returns record*"?? If "yes", the *record* datatype is somewhat outdated? The second question/discussion shows a more deeper problem, where perhaps the use of string index in array syntax (something like x['a']) would be a good syntax solution. Craig Ringer shows another suggestion in the (second) link. I am new here, I do not know how, but I'm available to help... Can a future version of PostgreSQL implement some solution? Peter
Re: [HACKERS] pg_get_viewdefs() indentation considered harmful
On 05/03/2014 09:17 AM, Marko Tiikkaja wrote: Hi all, Now that we're on the topic of view deparsing, what are your thoughts on making this less painful? local:marko=#* create view foov as select exists(select * from foo); CREATE VIEW local:marko=#* \d+ foov View "public.foov" Column | Type | Modifiers | Storage | Description +-+---+-+- exists | boolean | | plain | View definition: SELECT (EXISTS ( SELECT foo.way, foo.too, foo.many, foo.columns, foo.here FROM foo)) AS "exists"; I've switched to using SELECT 1 in EXISTS for this reason, but perhaps other people haven't yet done that.. I've done that for quite a few years. I think it's better style than using *. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_get_viewdefs() indentation considered harmful
Hi all, Now that we're on the topic of view deparsing, what are your thoughts on making this less painful? local:marko=#* create view foov as select exists(select * from foo); CREATE VIEW local:marko=#* \d+ foov View "public.foov" Column | Type | Modifiers | Storage | Description +-+---+-+- exists | boolean | | plain | View definition: SELECT (EXISTS ( SELECT foo.way, foo.too, foo.many, foo.columns, foo.here FROM foo)) AS "exists"; I've switched to using SELECT 1 in EXISTS for this reason, but perhaps other people haven't yet done that.. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Supporting multiple column assignment in UPDATE (9.5 project)
On 5/2/14, 10:10 PM, Merlin Moncure wrote: On Fri, May 2, 2014 at 3:03 PM, Tom Lane wrote: Meh. Then you could have a query that works fine until you add a column to the table, and it stops working. If nobody ever used column names identical to table names it'd be all right, but unfortunately people seem to do that a lot... That's already the case with select statements I don't think that's true if you table-qualify your column references and don't use SELECT *. and, if a user were concerned about that, always have the option of aliasing the table as nearly 100% of professional developers do: SELECT f FROM foo f; etc. So e.g.: UPDATE foo f SET f = ..; would resolve to the table, despite there being a column called "f"? That would break backwards compatibility. How about: UPDATE foo SET ROW(foo) = (1,2,3); ISTM that this could be parsed unambiguously, though it's perhaps a bit ugly. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sending out a request for more buildfarm animals?
Hamid@EDB; Can you please have someone configure anole to build git head as well as the other branches? Thanks. Andres, Andrew; I think the only other gap EDB could fill at the moment is RHEL6 on Power7 (though we do have a couple of Power8 boxes on order that should be here pretty soon). Dotterel is building some branches (including head). I'm not sure what generation of Power CPU that box has. Bernd? On Fri, May 2, 2014 at 4:04 PM, Andres Freund wrote: > Hi, > > There's pretty little coverage of non mainstream platforms/compilers in > the buildfarm atm. Maybe we should send an email on -announce asking for > new ones? > There's no coverage for OS-wise; > * AIX (at all) > * HP-UX (for master at least) > (* Tru64) > (* UnixWare) > > Architecture wise there's no coverage for: > * some ARM architecture varians > * mips > * s390/x > * sparc 32bit > (* s390) > (* alpha) > (* mipsel) > (* M68K) > > A couple of those aren't that important (my opinion indicated by ()), > but the other ones really should be covered or desupported. > > Greetings, > > Andres Freund > > -- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services -- Dave Page Chief Architect, Tools & Installers EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company Blog: http://pgsnake.blogspot.com Twitter: @pgsnake -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] quiet inline configure check misses a step for clang
On 2014-05-01 16:17:17 -0400, Tom Lane wrote: > Andres Freund writes: > > Patch attached. > > Committed with minor comment-smithing. Interestingly this seems to have allowed the quiet inline test to succeedd on HP-UX ac++ as well: http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=anole&dt=2014-05-02%2023%3A36%3A53&stg=config Seems it uses a similar logic to clang. For a lot longer. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] tab completion for setting search_path
On 2014-05-03 00:13:45 -0700, Jeff Janes wrote: > On Friday, May 2, 2014, Jeff Janes wrote: > > > I've been working with an app that uses a schema name whose spelling is > > hard to type, and the lack of tab completion for "SET search_path TO" was > > bugging me. So see attached. > > > > I filter out the system schemata, but not public. That'd be nice. > diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c > new file mode 100644 > index 6d26ffc..dec3d4a > *** a/src/bin/psql/tab-complete.c > --- b/src/bin/psql/tab-complete.c > *** psql_completion(const char *text, int st > *** 3230,3235 > --- 3230,3242 > > COMPLETE_WITH_LIST(my_list); > } > + else if (pg_strcasecmp(prev2_wd, "search_path") == 0) > + { > + COMPLETE_WITH_QUERY(Query_for_list_of_schemas > + " AND nspname > not like 'pg\\_%%' " > + " AND nspname > not like 'information_schema' " > + " UNION SELECT > 'DEFAULT' "); > + } Why should we exclude system schemata? That seems more likely to be confusing than helpful? I can see a point in excluding another backend's temp tables, but otherwise? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sending out a request for more buildfarm animals?
On 2014-05-02 21:07:55 -0400, Noah Misch wrote: > On Fri, May 02, 2014 at 05:04:01PM +0200, Andres Freund wrote: > > There's pretty little coverage of non mainstream platforms/compilers in > > the buildfarm atm. Maybe we should send an email on -announce asking for > > new ones? > > There's no coverage for OS-wise; > > * AIX (at all) > > * HP-UX (for master at least) > > (* Tru64) > > (* UnixWare) > > > > Architecture wise there's no coverage for: > > * some ARM architecture varians > > * mips > > * s390/x > > * sparc 32bit > > (* s390) > > (* alpha) > > (* mipsel) > > (* M68K) > > > > A couple of those aren't that important (my opinion indicated by ()), > > but the other ones really should be covered or desupported. > > More coverage of non-gcc compilers would be an asset to the buildfarm. > > +1 for sending a call for help to -announce. I agree with your importance > estimates, particularly on the OS side. -1 for making code-level changes to > "desupport" a platform based on the lack of a buildfarm member, though I don't > mind documentation/advocacy changes on that basis. I was thinking of changing http://www.postgresql.org/docs/devel/static/supported-platforms.html to list untested platforms similar to the way M32R and VAX are documented. I.e. code exists, but we have no clue whether it works. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] New and interesting replication issues with 9.2.8 sync rep
On 2014-05-02 18:57:08 -0700, Josh Berkus wrote: > Just got a report of a replication issue with 9.2.8 from a community member: > > Here's the sequence: > > 1) A --> B (sync rep) > > 2) Shut down B > > 3) Shut down A > > 4) Start up B as a master > > 5) Start up A as sync replica of B > > 6) A successfully joins B as a sync replica, even though its transaction > log is 1016 bytes *ahead* of B. > > 7) Transactions written to B all hang > > 8) Xlog on A is now corrupt, although the database itself is OK This is fundamentally borked practice. > Now, the above sequence happened because of the user misunderstanding > what sync rep really means. However, A should not have been able to > connect with B in replication mode, especially in sync rep mode; that > should have failed. Any thoughts on why it didn't? I'd guess that B, while starting up, has written further WAL records bringing it further ahead of A. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] tab completion for setting search_path
On Friday, May 2, 2014, Jeff Janes wrote: > I've been working with an app that uses a schema name whose spelling is > hard to type, and the lack of tab completion for "SET search_path TO" was > bugging me. So see attached. > > I filter out the system schemata, but not public. > > For commit fest next. > Once more, with attachment Cheers, Jeff diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c new file mode 100644 index 6d26ffc..dec3d4a *** a/src/bin/psql/tab-complete.c --- b/src/bin/psql/tab-complete.c *** psql_completion(const char *text, int st *** 3230,3235 --- 3230,3242 COMPLETE_WITH_LIST(my_list); } + else if (pg_strcasecmp(prev2_wd, "search_path") == 0) + { + COMPLETE_WITH_QUERY(Query_for_list_of_schemas + " AND nspname not like 'pg\\_%%' " + " AND nspname not like 'information_schema' " + " UNION SELECT 'DEFAULT' "); + } else { static const char *const my_list[] = -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers