Re: [HACKERS] psql shows line number
2013/11/26 22:24 Pavel Stehule pavel.steh...@gmail.com: 2013/11/26 Sawada Masahiko sawada.m...@gmail.com On Tue, Nov 26, 2013 at 9:23 PM, Marko Tiikkaja ma...@joh.to wrote: On 11/26/13 1:05 PM, Sawada Masahiko wrote: When I execute query which contains error, the server returns error with line number. ERROR: relation hoge does not exist LINE 35: hoge; But when query is long, I was not sure the location where I wrote wrong SQL. Does the psql have option which shows line number? If no, I'm thinking to implement this feature. Thought? I think it is useful if the psql shows line number like follows If the query is long, you'll likely want to \e to edit it anyway, no? I'm sure any text editor worth $EDITOR will know how to jump to a specific line. Thanks! ¥e is also good. I didn't know this. I thought that showing line number on psql is light and simple. So I thought that psql can also have such feature as standard function. idea is interesting, but a proposed format is not clean (and little bit ugly, and can be barrier for copy from terminal to editor. Now, simple replace can be used for cleaning. Thanks! Yes, it is little ugly. I was also thinking to fill space of line number with whitespace. likes: [ 1]postgres=# SELECT [ 2]postgres=# hoge.col1 : [ 9]postgres=# FROM [ 10]postgres=# hoge; But I think that it is also something just isn't right. maybe we can introduce a command, that will print SQL from history with line numbers - like \sf+ I think that ¥sf+ shows definition of function. How should I use this? yes, but we can define new statement like \sq+ (Show Query) I understood. it looks good to me. it is similer to searching history(i.g., just push up-arrow-key)? Regards, Masahiko Sawada
Re: [HACKERS] psql shows line number
On 11/26/13 2:24 PM, Pavel Stehule wrote: yes, but we can define new statement like \sq+ (Show Query) There's already \p; might not be too difficult to add a \p+ which would also show the line numbers. 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] psql shows line number
Marko Tiikkaja ma...@joh.to writes: On 11/26/13 2:24 PM, Pavel Stehule wrote: yes, but we can define new statement like \sq+ (Show Query) There's already \p; might not be too difficult to add a \p+ which would also show the line numbers. I don't actually see the point of this. If you're working with queries that are long enough that counting lines is even slightly difficult, surely you're going to use \e to correct the problem? So it seems to me that the existing \e nnn facility pretty much does what's needed, and there's no great need to clutter your regular display with line numbers. 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] psql shows line number
On Tue, Nov 26, 2013 at 9:22 AM, Tom Lane t...@sss.pgh.pa.us wrote: Marko Tiikkaja ma...@joh.to writes: On 11/26/13 2:24 PM, Pavel Stehule wrote: yes, but we can define new statement like \sq+ (Show Query) There's already \p; might not be too difficult to add a \p+ which would also show the line numbers. I don't actually see the point of this. If you're working with queries that are long enough that counting lines is even slightly difficult, surely you're going to use \e to correct the problem? So it seems to me that the existing \e nnn facility pretty much does what's needed, and there's no great need to clutter your regular display with line numbers. I agree in the sense line numbers don't help. But \e is not really a solution to the problem. A pretty common thing for me to see (as an artifact of my styling) in the log: ERROR: syntax error at or near from LINE 223: from ^ Not very helpful. Also good luck if your SQL is dynamically generated. What I think would help *would* be able to optionally add a some lines of context: then you'd at least have a shot at eyeballing the error etc. merlin -- 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] psql should show disabled internal triggers
On Fri, Oct 25, 2013 at 3:37 PM, fabriziomello fabriziome...@gmail.com wrote: On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote: On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote: --On 18. September 2013 13:52:29 +0200 Andres Freund lt;andres@gt; wrote: If you do ALTER TABLE ... DISABLE TRIGGER ALL; and then individually re-enable the disabled triggers it's easy to miss internal triggers. A \d+ tablename will not show anything out of the ordinary for that situation since we don't show internal triggers. But foreign key checks won't work. So, how about displaying disabled internal triggers in psql? Hi had exactly the same concerns this morning while starting to look at the ENABLE/DISABLE constraint patch. However, i wouldn't display them as triggers, but maybe more generally as disabled constraints or such. Well, that will lead the user in the wrong direction, won't it? They haven't disabled the constraint but the trigger. Especially as we already have NOT VALID and might grow DISABLED for constraint themselves... Hi, The attached patch [1] enable PSQL to list internal disabled triggers in \d only in versions = 9.0. [1] psql-display-all-triggers-v1.patch http://postgresql.1045698.n5.nabble.com/file/n5775954/psql-display-all-triggers-v1.patch Hi all, I'm just send a new WIP patch rebased from master. Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Timbira: http://www.timbira.com.br Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c index 96322ca..f457e21 100644 --- a/src/bin/psql/describe.c +++ b/src/bin/psql/describe.c @@ -2079,7 +2079,7 @@ describeOneTableDetails(const char *schemaname, (pset.sversion = 9 ? , true : ), oid); if (pset.sversion = 9) - appendPQExpBufferStr(buf, NOT t.tgisinternal); + appendPQExpBuffer(buf, (NOT t.tgisinternal OR (t.tgisinternal AND t.tgenabled = 'D'))); else if (pset.sversion = 80300) appendPQExpBufferStr(buf, t.tgconstraint = 0); else -- 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] psql: small patch to correct filename formatting error in '\s FILE' output
Ian Lawrence Barwick barw...@gmail.com writes: 2013/9/10 Bruce Momjian br...@momjian.us: I still see that weird behavior in git head: pgdevel=# \s history.txt Wrote history to file ./history.txt. pgdevel=# \s /tmp/history.txt Wrote history to file .//tmp/history.txt. pgdevel=# \cd /tmp pgdevel=# \s /tmp/history.txt Wrote history to file /tmp//tmp/history.txt. Should I revert the suggested patch? IIRC the patch was never applied, the reversion candidate is the existing commit 0725065b. I reverted 0725065b. AFAICT there is no interest in making \s produce a reliable full path name. There was some interest in making \cd tell you where it'd chdir'd to, but that would be a separate patch. 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] psql should show disabled internal triggers
On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote: On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote: --On 18. September 2013 13:52:29 +0200 Andres Freund lt;andres@gt; wrote: If you do ALTER TABLE ... DISABLE TRIGGER ALL; and then individually re-enable the disabled triggers it's easy to miss internal triggers. A \d+ tablename will not show anything out of the ordinary for that situation since we don't show internal triggers. But foreign key checks won't work. So, how about displaying disabled internal triggers in psql? Hi had exactly the same concerns this morning while starting to look at the ENABLE/DISABLE constraint patch. However, i wouldn't display them as triggers, but maybe more generally as disabled constraints or such. Well, that will lead the user in the wrong direction, won't it? They haven't disabled the constraint but the trigger. Especially as we already have NOT VALID and might grow DISABLED for constraint themselves... Hi, The attached patch [1] enable PSQL to list internal disabled triggers in \d only in versions = 9.0. [1] psql-display-all-triggers-v1.patch http://postgresql.1045698.n5.nabble.com/file/n5775954/psql-display-all-triggers-v1.patch Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Timbira: http://www.timbira.com.br Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello - -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello -- View this message in context: http://postgresql.1045698.n5.nabble.com/psql-should-show-disabled-internal-triggers-tp5771406p5775954.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] psql tab completion for updatable foreign tables
On Sat, Oct 19, 2013 at 5:44 AM, Dean Rasheed dean.a.rash...@gmail.com wrote: On 18 October 2013 16:41, Robert Haas robertmh...@gmail.com wrote: On Fri, Oct 18, 2013 at 1:34 AM, Dean Rasheed dean.a.rash...@gmail.com wrote: Personally, I think this is too fancy anyway. I'd just complete all views and foreign tables and be done with it. We don't inspect permissions either, for example. This might be too confusing for users. Yeah, I think you're probably right. I tend to agree. When the rules were simple (i.e. pretty much nothing was updateable) it might have made sense to make tab completion hew to them, but they're complex enough now that I think it no longer does. There are now three different ways that a view can be updateable (auto, trigger, rule) and the rules are complex. Based on that it sounds like we need a new version of this patch. If that's not going to happen RSN, we should mark this returned with feedback and it can be resubmitted if and when someone finds the time to update it. OK, here's a new version that just completes with all tables, views and foreign tables. Doing this makes the insert, update and delete queries all the same, which means there's not much point in keeping all three, so I've just kept Query_for_list_of_updatables for use with INSERT, UPDATE and DELETE. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] psql built from git still reports 9.3devel
On Mon, Oct 21, 2013 at 9:09 PM, Colin 't Hart colinth...@gmail.com wrote: git status says that I'm on branch master. psql reports 9.3devel, yet I expected it to report 9.4devel Is this expected behaviour? I've looked at the developer's FAQ and Wiki but couldn't find anything about this. You should check your installation, here is what I am getting in my dev box: $ psql --version psql (PostgreSQL) 9.4devel Regards, -- Michael -- 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] psql built from git still reports 9.3devel
make distclean ./configure make sudo make install helped. Cheers, Colin On 21 October 2013 14:25, Michael Paquier michael.paqu...@gmail.com wrote: On Mon, Oct 21, 2013 at 9:09 PM, Colin 't Hart colinth...@gmail.com wrote: git status says that I'm on branch master. psql reports 9.3devel, yet I expected it to report 9.4devel Is this expected behaviour? I've looked at the developer's FAQ and Wiki but couldn't find anything about this. You should check your installation, here is what I am getting in my dev box: $ psql --version psql (PostgreSQL) 9.4devel Regards, -- Michael
Re: [HACKERS] psql tab completion for updatable foreign tables
On 18 October 2013 16:41, Robert Haas robertmh...@gmail.com wrote: On Fri, Oct 18, 2013 at 1:34 AM, Dean Rasheed dean.a.rash...@gmail.com wrote: Personally, I think this is too fancy anyway. I'd just complete all views and foreign tables and be done with it. We don't inspect permissions either, for example. This might be too confusing for users. Yeah, I think you're probably right. I tend to agree. When the rules were simple (i.e. pretty much nothing was updateable) it might have made sense to make tab completion hew to them, but they're complex enough now that I think it no longer does. There are now three different ways that a view can be updateable (auto, trigger, rule) and the rules are complex. Based on that it sounds like we need a new version of this patch. If that's not going to happen RSN, we should mark this returned with feedback and it can be resubmitted if and when someone finds the time to update it. OK, here's a new version that just completes with all tables, views and foreign tables. Doing this makes the insert, update and delete queries all the same, which means there's not much point in keeping all three, so I've just kept Query_for_list_of_updatables for use with INSERT, UPDATE and DELETE. Regards, Dean tab_complete.v3.patch Description: Binary data -- 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] psql tab completion for updatable foreign tables
On Fri, Oct 18, 2013 at 1:34 AM, Dean Rasheed dean.a.rash...@gmail.com wrote: Personally, I think this is too fancy anyway. I'd just complete all views and foreign tables and be done with it. We don't inspect permissions either, for example. This might be too confusing for users. Yeah, I think you're probably right. I tend to agree. When the rules were simple (i.e. pretty much nothing was updateable) it might have made sense to make tab completion hew to them, but they're complex enough now that I think it no longer does. There are now three different ways that a view can be updateable (auto, trigger, rule) and the rules are complex. Based on that it sounds like we need a new version of this patch. If that's not going to happen RSN, we should mark this returned with feedback and it can be resubmitted if and when someone finds the time to update it. Thanks, -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] psql tab completion for updatable foreign tables
On 17 October 2013 03:29, Peter Eisentraut pete...@gmx.net wrote: On Mon, 2013-07-08 at 16:04 +, Dean Rasheed wrote: There was concern that pg_relation_is_updatable() would end up opening every relation in the database, hammering performance. I now realise that these tab-complete queries have a limit (1000 by default) so I don't think this is such an issue. I tested it by creating 10,000 randomly named auto-updatable views on top of a table, and didn't see any performance problems. Even if performance isn't a problem, do we really want tab completion interfering with table locking? That might be a step too far. That's a good point. Currently it's calling pg_table_is_visible(), which is doing similar work opening each relation, but it isn't locking any of them. Personally, I think this is too fancy anyway. I'd just complete all views and foreign tables and be done with it. We don't inspect permissions either, for example. This might be too confusing for users. Yeah, I think you're probably right. Regards, Dean -- 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] psql tab completion for updatable foreign tables
On Mon, 2013-07-08 at 16:04 +, Dean Rasheed wrote: There was concern that pg_relation_is_updatable() would end up opening every relation in the database, hammering performance. I now realise that these tab-complete queries have a limit (1000 by default) so I don't think this is such an issue. I tested it by creating 10,000 randomly named auto-updatable views on top of a table, and didn't see any performance problems. Even if performance isn't a problem, do we really want tab completion interfering with table locking? That might be a step too far. Personally, I think this is too fancy anyway. I'd just complete all views and foreign tables and be done with it. We don't inspect permissions either, for example. This might be too confusing for users. -- 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] PSQL return coder
I was avoiding ON_ERROR_STOP because I was using ON_ERROR_ROLLBACK, but have just realised that if I encase my SQL in a transaction then rollback will still happen. Perfect! James Sewell, PostgreSQL Team Lead / Solutions Architect __ Level 2, 50 Queen St, Melbourne VIC 3000 *P *(+61) 3 8370 8000 * **W* www.lisasoft.com *F *(+61) 3 8370 8099 On Fri, Oct 11, 2013 at 12:25 AM, Merlin Moncure mmonc...@gmail.com wrote: On Thu, Oct 10, 2013 at 1:52 AM, Tom Lane t...@sss.pgh.pa.us wrote: James Sewell james.sew...@lisasoft.com writes: My question is in a rollback scenario is it possible to get PSQL to return a non 0 exit status? Maybe you could use -c instead of -f? $ psql -c 'select 1; select 1/0' regression ERROR: division by zero $ echo $? 1 You won't need explicit BEGIN/END because this is already a single transaction. According to the man page, EXIT STATUS psql returns 0 to the shell if it finished normally, 1 if a fatal error of its own (out of memory, file not found) occurs, 2 if the connection to the server went bad and the session was not interactive, and 3 if an error occurred in a script and the variable ON_ERROR_STOP was set. So for a longer script ON_ERROR_STOP might be the ticket (which is usually a good idea anyways). merlin -- -- The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence.
Re: [HACKERS] psql tab completion for updatable foreign tables
On Fri, Sep 20, 2013 at 7:54 PM, Dean Rasheed dean.a.rash...@gmail.comwrote: On 20 September 2013 11:29, Samrat Revagade revagade.sam...@gmail.com wrote: Okay, are you adding this to the september commitfest? OK, I've done that. I think that it's too late for 9.3. +1 for idea. I have tested patch and got surprising results with Cent-OS Patch is working fine for Cent-OS 6.2 and RHEL 6.3 But is is giving problem on Cent-OS 6.3 (tab complete for local tables but not for foreign tables) I have used following script: Two postgres servers are running by using ports 5432 and 5433. Server with port 5432 has postgres_fdw installed and will interact with the remote server running under port 5433. psql -p 5433 -c CREATE TABLE aa_remote (a int, b int) postgres postgres=# CREATE EXTENSION postgres_fdw; postgres=# CREATE SERVER postgres_server FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host 'localhost', port '5433', dbname 'postgres'); postgres=# CREATE USER MAPPING FOR PUBLIC SERVER postgres_server OPTIONS (password ''); postgres=# CREATE FOREIGN TABLE aa_foreign (a int, b int) SERVER postgres_server OPTIONS (table_name 'aa_remote'); postgres=# INSERT into aa_foreign values (1,2); But while doing any operation on aa_foreign tab do not complete on Cent-OS 6.3 (tab complete for local tables but not for foreign tables) Is that a problem ? Hmm. It works for me. What does pg_relation_is_updatable() return for your foreign table? Sorry .my environment has some problem. when I compiled it with fresh installation of Cent-OS 6.3 it worked. Patch : 1. Applies cleanly to git master 2. Has necessary source code comments 3. Follows coding standards 4. Solves use case.
Re: [HACKERS] psql tab completion for updatable foreign tables
On Mon, Oct 14, 2013 at 7:20 PM, Samrat Revagade revagade.sam...@gmail.comwrote: Sorry .my environment has some problem. May be you were using old version of psql ? IIRC tab-completion relies heavily on the psql side, Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee
Re: [HACKERS] PSQL return coder
James Sewell james.sew...@lisasoft.com writes: My question is in a rollback scenario is it possible to get PSQL to return a non 0 exit status? Maybe you could use -c instead of -f? $ psql -c 'select 1; select 1/0' regression ERROR: division by zero $ echo $? 1 You won't need explicit BEGIN/END because this is already a single transaction. 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] PSQL return coder
On Thu, Oct 10, 2013 at 1:52 AM, Tom Lane t...@sss.pgh.pa.us wrote: James Sewell james.sew...@lisasoft.com writes: My question is in a rollback scenario is it possible to get PSQL to return a non 0 exit status? Maybe you could use -c instead of -f? $ psql -c 'select 1; select 1/0' regression ERROR: division by zero $ echo $? 1 You won't need explicit BEGIN/END because this is already a single transaction. According to the man page, EXIT STATUS psql returns 0 to the shell if it finished normally, 1 if a fatal error of its own (out of memory, file not found) occurs, 2 if the connection to the server went bad and the session was not interactive, and 3 if an error occurred in a script and the variable ON_ERROR_STOP was set. So for a longer script ON_ERROR_STOP might be the ticket (which is usually a good idea anyways). merlin -- 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] PSQL return coder
Hello 2013/10/10 James Sewell james.sew...@lisasoft.com Hello, I am using PSQL to run SQL from a file with the -f flag as follows: BEGIN SQL SQL ... END This gives me rollback on error and a nicer output than -1. This works fine. My question is in a rollback scenario is it possible to get PSQL to return a non 0 exit status? probably not - from psql perspective all statements was perfect Pavel Cheers,a James -- James Sewell, PostgreSQL Team Lead / Solutions Architect __ Level 2, 50 Queen St, Melbourne VIC 3000 *P *(+61) 3 8370 8000 * **W* www.lisasoft.com *F *(+61) 3 8370 8099 -- The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence.
Re: [HACKERS] psql tab completion for updatable foreign tables
Okay, are you adding this to the september commitfest? OK, I've done that. I think that it's too late for 9.3. +1 for idea. I have tested patch and got surprising results with Cent-OS Patch is working fine for Cent-OS 6.2 and RHEL 6.3 But is is giving problem on Cent-OS 6.3 (tab complete for local tables but not for foreign tables) I have used following script: Two postgres servers are running by using ports 5432 and 5433. Server with port 5432 has postgres_fdw installed and will interact with the remote server running under port 5433. psql -p 5433 -c CREATE TABLE aa_remote (a int, b int) postgres postgres=# CREATE EXTENSION postgres_fdw; postgres=# CREATE SERVER postgres_server FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host 'localhost', port '5433', dbname 'postgres'); postgres=# CREATE USER MAPPING FOR PUBLIC SERVER postgres_server OPTIONS (password ''); postgres=# CREATE FOREIGN TABLE aa_foreign (a int, b int) SERVER postgres_server OPTIONS (table_name 'aa_remote'); postgres=# INSERT into aa_foreign values (1,2); But while doing any operation on aa_foreign tab do not complete on Cent-OS 6.3 (tab complete for local tables but not for foreign tables) Is that a problem ? Regards, Samrat Revagade
Re: [HACKERS] psql tab completion for updatable foreign tables
On 20 September 2013 11:29, Samrat Revagade revagade.sam...@gmail.com wrote: Okay, are you adding this to the september commitfest? OK, I've done that. I think that it's too late for 9.3. +1 for idea. I have tested patch and got surprising results with Cent-OS Patch is working fine for Cent-OS 6.2 and RHEL 6.3 But is is giving problem on Cent-OS 6.3 (tab complete for local tables but not for foreign tables) I have used following script: Two postgres servers are running by using ports 5432 and 5433. Server with port 5432 has postgres_fdw installed and will interact with the remote server running under port 5433. psql -p 5433 -c CREATE TABLE aa_remote (a int, b int) postgres postgres=# CREATE EXTENSION postgres_fdw; postgres=# CREATE SERVER postgres_server FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host 'localhost', port '5433', dbname 'postgres'); postgres=# CREATE USER MAPPING FOR PUBLIC SERVER postgres_server OPTIONS (password ''); postgres=# CREATE FOREIGN TABLE aa_foreign (a int, b int) SERVER postgres_server OPTIONS (table_name 'aa_remote'); postgres=# INSERT into aa_foreign values (1,2); But while doing any operation on aa_foreign tab do not complete on Cent-OS 6.3 (tab complete for local tables but not for foreign tables) Is that a problem ? Hmm. It works for me. What does pg_relation_is_updatable() return for your foreign table? Regards, Dean -- 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] psql sets up cancel handler very early
On 14 May 2013 16:35, Peter Eisentraut pete...@gmx.net wrote: Sometimes, the psql startup hangs when it cannot resolve or connect to a host. Intuitively, I would like to press Ctrl+C and correct the connection string or investigate. But that doesn't work because Ctrl+C is already bound to the query cancel handler by that time. It seems to me that there is no point in setting up the cancel handler before the database connection is established. Example patch attached. Comments? That makes sense to me, and the patch appears to work as advertised. The objections to the previous patch were that it did nothing in the \c case, or if the server becomes unreachable mid-session. Those feel like much less common cases, but maybe they're still worth thinking about. However, IMO the solution to those issues is likely to be a significantly different (and larger) patch. Also, even if those issues do get addressed one day, the change in this patch still seems like the right thing to do on initial startup, which IME is the most common case, so +1 for this patch. I'm marking it ready for committer. Regards, Dean -- 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] psql should show disabled internal triggers
Andres Freund and...@2ndquadrant.com writes: So, how about displaying disabled internal triggers in psql? +1 -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- 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] psql should show disabled internal triggers
--On 18. September 2013 13:52:29 +0200 Andres Freund and...@2ndquadrant.com wrote: If you do ALTER TABLE ... DISABLE TRIGGER ALL; and then individually re-enable the disabled triggers it's easy to miss internal triggers. A \d+ tablename will not show anything out of the ordinary for that situation since we don't show internal triggers. But foreign key checks won't work. So, how about displaying disabled internal triggers in psql? Hi had exactly the same concerns this morning while starting to look at the ENABLE/DISABLE constraint patch. However, i wouldn't display them as triggers, but maybe more generally as disabled constraints or such. -- Thanks Bernd -- 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] psql should show disabled internal triggers
On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote: --On 18. September 2013 13:52:29 +0200 Andres Freund and...@2ndquadrant.com wrote: If you do ALTER TABLE ... DISABLE TRIGGER ALL; and then individually re-enable the disabled triggers it's easy to miss internal triggers. A \d+ tablename will not show anything out of the ordinary for that situation since we don't show internal triggers. But foreign key checks won't work. So, how about displaying disabled internal triggers in psql? Hi had exactly the same concerns this morning while starting to look at the ENABLE/DISABLE constraint patch. However, i wouldn't display them as triggers, but maybe more generally as disabled constraints or such. Well, that will lead the user in the wrong direction, won't it? They haven't disabled the constraint but the trigger. Especially as we already have NOT VALID and might grow DISABLED for constraint themselves... 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] psql should show disabled internal triggers
--On 18. September 2013 15:19:27 +0200 Andres Freund and...@2ndquadrant.com wrote: Well, that will lead the user in the wrong direction, won't it? They haven't disabled the constraint but the trigger. Especially as we already have NOT VALID and might grow DISABLED for constraint themselves... Valid point. But it is also nice to know in detail, which constraints stopped working. Ok, it is documented which constraints are affected and maybe i'm lost within too much detail atm, but i find people getting confused about this internal trigger thingie sometimes. Won't they get confused about a suddenly appearing RI_ConstraintTrigger_a_54015, too? -- Thanks Bernd -- 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] psql: small patch to correct filename formatting error in '\s FILE' output
On Tue, Jan 22, 2013 at 07:30:59PM -0500, Tom Lane wrote: Ian Lawrence Barwick barw...@gmail.com writes: Related email from the archives on this subject: http://www.postgresql.org/message-id/37ed240d0611200645l5b70c8ddw5fb735e0d35a7...@mail.gmail.com I agree with the opinion stated there that \cd with no argument really ought to do what cd with no argument usually does on the platform. So if we're going to fix \cd to print the resulting current directory, wouldn't it work to just set dir to . rather than / for Windows? Does commit 0725065b just need to be reverted, or is an additional patch required to remove the prefixed working directory from \s output? Offhand it looked like reverting the commit would be enough, but I didn't look hard to see if there had been any subsequent related changes. [ pokes around... ] Well, at least there are still no other uses of pset.dirname. I still see that weird behavior in git head: pgdevel=# \s history.txt Wrote history to file ./history.txt. pgdevel=# \s /tmp/history.txt Wrote history to file .//tmp/history.txt. pgdevel=# \cd /tmp pgdevel=# \s /tmp/history.txt Wrote history to file /tmp//tmp/history.txt. Should I revert the suggested patch? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] psql: small patch to correct filename formatting error in '\s FILE' output
2013/9/10 Bruce Momjian br...@momjian.us: On Tue, Jan 22, 2013 at 07:30:59PM -0500, Tom Lane wrote: Ian Lawrence Barwick barw...@gmail.com writes: Related email from the archives on this subject: http://www.postgresql.org/message-id/37ed240d0611200645l5b70c8ddw5fb735e0d35a7...@mail.gmail.com I agree with the opinion stated there that \cd with no argument really ought to do what cd with no argument usually does on the platform. So if we're going to fix \cd to print the resulting current directory, wouldn't it work to just set dir to . rather than / for Windows? Does commit 0725065b just need to be reverted, or is an additional patch required to remove the prefixed working directory from \s output? Offhand it looked like reverting the commit would be enough, but I didn't look hard to see if there had been any subsequent related changes. [ pokes around... ] Well, at least there are still no other uses of pset.dirname. I still see that weird behavior in git head: pgdevel=# \s history.txt Wrote history to file ./history.txt. pgdevel=# \s /tmp/history.txt Wrote history to file .//tmp/history.txt. pgdevel=# \cd /tmp pgdevel=# \s /tmp/history.txt Wrote history to file /tmp//tmp/history.txt. Should I revert the suggested patch? IIRC the patch was never applied, the reversion candidate is the existing commit 0725065b. (Sorry for not following up earlier, this one dropped off my radar). Regards Ian Barwick -- 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] psql and pset without any arguments
Patch added to current open commitfest under the Client section with title: Call \pset without any arguments displays current status of all printing options Status: Need review. Let me know if it should not be there. Regards, Le 29/06/2013 01:08, Gilles Darold a écrit : Hi, I was looking at psql 8.3 documention about \pset options and saw that there was the following note : Note: It is an error to call \pset without any arguments. In the future this case might show the current status of all printing options. I looked backward and forward to find that this note is present in all versions since 7.1 up to 9.3, maybe it is time to add this little feature. I've attached a patch to add the usage of the \pset command without any arguments to displays current status of all printing options instead of the error message. Here is a sample output: (postgres@[local]:5494) [postgres] \pset Output format is aligned. Border style is 2. Expanded display is used automatically. Null display is NULL. Field separator is |. Tuples only is off. Title is unset. Table attributes unset. Line style is unicode. Pager is used for long output. Record separator is newline. (postgres@[local]:5494) [postgres] To avoid redundant code I've added a new method printPsetInfo() so that do_pset() and exec_command() will used the same output message, they are all in src/bin/psql/command.c. For example: (postgres@[local]:5494) [postgres] \pset null 'NULL' Null display is NULL. (postgres@[local]:5494) [postgres] The patch print all variables information from struct printTableOpt when \pset is given without any arguments and also update documentation. Let me know if there's any additional work to do on this basic patch or something that I've omitted. Best regards, -- Gilles Darold http://dalibo.com - http://dalibo.org -- 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] psql missing tab completion for extensions
Magnus Hagander mag...@hagander.net writes: Magnus Hagander mag...@hagander.net writes: psql is missing tab completion for \dx (or more usfully, for \dx+). Attached patch fixes this. Done. Thanks! Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- 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] psql missing tab completion for extensions
Magnus Hagander mag...@hagander.net writes: psql is missing tab completion for \dx (or more usfully, for \dx+). Attached patch fixes this. Do we consider this a bugfix and backpatch (at least to 9.3? even though the problem goes back further), or head only? Sounds like a feature to me. I wouldn't object to sneaking it into 9.3 though. 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] psql missing tab completion for extensions
* Tom Lane (t...@sss.pgh.pa.us) wrote: Magnus Hagander mag...@hagander.net writes: psql is missing tab completion for \dx (or more usfully, for \dx+). Attached patch fixes this. Do we consider this a bugfix and backpatch (at least to 9.3? even though the problem goes back further), or head only? Sounds like a feature to me. I wouldn't object to sneaking it into 9.3 though. Agreed. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] psql missing tab completion for extensions
On Thu, Aug 15, 2013 at 5:26 PM, Stephen Frost sfr...@snowman.net wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: Magnus Hagander mag...@hagander.net writes: psql is missing tab completion for \dx (or more usfully, for \dx+). Attached patch fixes this. Do we consider this a bugfix and backpatch (at least to 9.3? even though the problem goes back further), or head only? Sounds like a feature to me. I wouldn't object to sneaking it into 9.3 though. Agreed. Done. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] psql --single-transaction does not work as expected
On Tue, Aug 13, 2013 at 04:04:50PM +0200, Rafael Martinez wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello I want to report that psql --single-transaction does not work as one can expect after reading the help information for psql. psql --help says: - -1 (one), --single-transaction: execute command file as a single transaction If you run psql -1 sql_file.sql insteed of psql -1 -f sql_file.sql the single-transaction parameter will not work. This will be fixed in PG 9.3; from the release notes: Allow the psql --single-transaction mode to work when reading from standard input (Fabien Coelho, Robert Haas) Previously this option only worked when reading from a file. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] psql tab completion for updatable foreign tables
On 11 July 2013 00:03, Bernd Helmle maili...@oopsware.de wrote: --On 8. Juli 2013 16:04:31 + Dean Rasheed dean.a.rash...@gmail.com wrote: * pg_relation_is_updatable is only available in 9.3, whereas psql may connect to older servers, so it needs to guard against that. Oh of course, i forgot about this. Thanks for pointing out. * If we're doing this, I think we should do it for auto-updatable views at the same time. There was concern that pg_relation_is_updatable() would end up opening every relation in the database, hammering performance. I now realise that these tab-complete queries have a limit (1000 by default) so I don't think this is such an issue. I tested it by creating 10,000 randomly named auto-updatable views on top of a table, and didn't see any performance problems. Here's an updated patch based on the above points. Okay, are you adding this to the september commitfest? OK, I've done that. I think that it's too late for 9.3. Regards, Dean -- 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] psql tab completion for updatable foreign tables
--On 8. Juli 2013 16:04:31 + Dean Rasheed dean.a.rash...@gmail.com wrote: * pg_relation_is_updatable is only available in 9.3, whereas psql may connect to older servers, so it needs to guard against that. Oh of course, i forgot about this. Thanks for pointing out. * If we're doing this, I think we should do it for auto-updatable views at the same time. There was concern that pg_relation_is_updatable() would end up opening every relation in the database, hammering performance. I now realise that these tab-complete queries have a limit (1000 by default) so I don't think this is such an issue. I tested it by creating 10,000 randomly named auto-updatable views on top of a table, and didn't see any performance problems. Here's an updated patch based on the above points. Okay, are you adding this to the september commitfest? -- Thanks Bernd -- 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] psql tab completion for updatable foreign tables
On 8 July 2013 12:46, Bernd Helmle maili...@oopsware.de wrote: Recently i got annoyed that psql doesn't tab complete to updatable foreign tables. Attached is a patch to address this. I'm using the new pg_relation_is_updatable() function to accomplish this. The function could also be used for the trigger based stuff in the query, but i haven't touched this part of the query. The patch ist against HEAD, but maybe it's worth to apply this to REL9_3_STABLE, too, but not sure what our policy is at this state... +1 A couple of points though: * pg_relation_is_updatable is only available in 9.3, whereas psql may connect to older servers, so it needs to guard against that. * If we're doing this, I think we should do it for auto-updatable views at the same time. There was concern that pg_relation_is_updatable() would end up opening every relation in the database, hammering performance. I now realise that these tab-complete queries have a limit (1000 by default) so I don't think this is such an issue. I tested it by creating 10,000 randomly named auto-updatable views on top of a table, and didn't see any performance problems. Here's an updated patch based on the above points. Regards, Dean tab_complete.patch Description: Binary data -- 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] psql and pset without any arguments
Von: pgsql-hackers-ow...@postgresql.org [pgsql-hackers-ow...@postgresql.org]quot; im Auftrag von quot;Gilles Darold [gilles.dar...@dalibo.com] I was looking at psql 8.3 documention about \pset options and saw that there was the following note : Note: It is an error to call \pset without any arguments. In the future this case might show the current status of all printing options. I looked backward and forward to find that this note is present in all versions since 7.1 up to 9.3, maybe it is time to add this little feature. I've attached a patch to add the usage of the \pset command without any arguments to displays current status of all printing options instead of the error message. Here is a sample output: (postgres@[local]:5494) [postgres] \pset Output format is aligned. Border style is 2. Expanded display is used automatically. Null display is NULL. Field separator is |. Tuples only is off. Title is unset. Table attributes unset. Line style is unicode. Pager is used for long output. Record separator is newline. (postgres@[local]:5494) [postgres] Hello, this is a nice additional feature. As a user (not a hacker), I would prefer to see the real parameter name instead of the display name. e.g. Border style is 2. = border = 2 without this, the user would not know out of the fly which parameter to modify... best regards, Marc Mamin To avoid redundant code I've added a new method printPsetInfo() so that do_pset() and exec_command() will used the same output message, they are all in src/bin/psql/command.c. For example: (postgres@[local]:5494) [postgres] \pset null 'NULL' Null display is NULL. (postgres@[local]:5494) [postgres] The patch print all variables information from struct printTableOpt when \pset is given without any arguments and also update documentation. Let me know if there's any additional work to do on this basic patch or something that I've omitted. Best regards, -- Gilles Darold http://dalibo.com - http://dalibo.org -- 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] psql and pset without any arguments
On Sat, June 29, 2013 01:08, Gilles Darold wrote: Here is a sample output: (postgres@[local]:5494) [postgres] \pset Output format is aligned. Border style is 2. Expanded display is used automatically. Null display is NULL. Field separator is |. Tuples only is off. Title is unset. Table attributes unset. Line style is unicode. Pager is used for long output. Record separator is newline. (postgres@[local]:5494) [postgres] +1 This seems handy. Maybe it could be improved a bit with the keyboard shortcuts prefixed, like so: (postgres@[local]:5494) [postgres] \pset \a Output format is aligned. \x Expanded display is used automatically. \f Field separator is |. \t Tuples only is off. \C Title is unset. \T Table attributes unset. Border style is 2. Line style is unicode. Null display is NULL. Pager is used for long output. Record separator is newline. So that it also serves a reminder on how to subsequently change them Thanks, Erik Rijkers -- 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] psql and pset without any arguments
2013/6/29 Erik Rijkers e...@xs4all.nl: On Sat, June 29, 2013 01:08, Gilles Darold wrote: Here is a sample output: (postgres@[local]:5494) [postgres] \pset Output format is aligned. Border style is 2. Expanded display is used automatically. Null display is NULL. Field separator is |. Tuples only is off. Title is unset. Table attributes unset. Line style is unicode. Pager is used for long output. Record separator is newline. (postgres@[local]:5494) [postgres] +1 This seems handy. Maybe it could be improved a bit with the keyboard shortcuts prefixed, like so: (postgres@[local]:5494) [postgres] \pset \a Output format is aligned. \x Expanded display is used automatically. \f Field separator is |. \t Tuples only is off. \C Title is unset. \T Table attributes unset. Border style is 2. Line style is unicode. Null display is NULL. Pager is used for long output. Record separator is newline. it is less readable - and same info you can get with \? Regards Pavel So that it also serves a reminder on how to subsequently change them Thanks, Erik Rijkers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] psql and pset without any arguments
Le 29/06/2013 13:55, Erik Rijkers a écrit : On Sat, June 29, 2013 01:08, Gilles Darold wrote: Here is a sample output: (postgres@[local]:5494) [postgres] \pset Output format is aligned. Border style is 2. Expanded display is used automatically. Null display is NULL. Field separator is |. Tuples only is off. Title is unset. Table attributes unset. Line style is unicode. Pager is used for long output. Record separator is newline. (postgres@[local]:5494) [postgres] +1 This seems handy. Maybe it could be improved a bit with the keyboard shortcuts prefixed, like so: (postgres@[local]:5494) [postgres] \pset \a Output format is aligned. \x Expanded display is used automatically. \f Field separator is |. \t Tuples only is off. \C Title is unset. \T Table attributes unset. Border style is 2. Line style is unicode. Null display is NULL. Pager is used for long output. Record separator is newline. So that it also serves a reminder on how to subsequently change them My first though was to print something like \set output, but why not reuse the original code/output when \pset is used ? This second choice has three main advantages : * Information shown is the same everywhere * Backward compatibility with \pset output * Avoid code redundancy About shortcut I'm agree with Pavel that it is less readable and already in the help, \? is the big reminder :-) Regards, -- Gilles Darold http://dalibo.com - http://dalibo.org -- 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] psql \dv+ shows view size as 0 bytes
On 4 June 2013 16:54, Peter Eisentraut pete...@gmx.net wrote: \dv+ shows the size of views as 0 bytes. This doesn't make any sense; I think it should show null. Maybe this is even the fault of the backend functions for returning a number to display in the first place. It doesn't sound useful whether it's 0 or NULL in that output. Why have the column in the first place when it can't have a value? Is it somehow required for inclusion in the output of \d+ ? -- Thom -- 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] psql \dv+ shows view size as 0 bytes
On 6/4/13 12:08 PM, Thom Brown wrote: It doesn't sound useful whether it's 0 or NULL in that output. Why have the column in the first place when it can't have a value? Is it somehow required for inclusion in the output of \d+ ? \dv is just a special case of \dvti... -- 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] psql \watch versus \timing
Jeff Janes jeff.ja...@gmail.com writes: I'd like to run same query repeatedly and see how long it takes each time. I thought \watch would be excellent for this, but it turns out that using \watch suppresses the output of \timing. Is this intentional, or unavoidable? \watch uses PSQLexec not SendQuery; the latter implements \timing which I agree is arguably useful here, but also autocommit/auto-savepoint behavior which probably isn't a good idea. It might be a good idea to refactor those two routines into one routine with some sort of bitmap flags argument to control the various add-on behaviors, but that seems like not 9.3 material anymore. Also, is it just or does the inability to watch more frequently than once a second make it a lot less useful than it could be? It did not seem that exciting to me. In particular, we've already found out that \watch with zero delay is a pretty bad idea, so you'd have to make a case for what smaller minimum to use if it's not to be 1 second. 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] psql sets up cancel handler very early
I submitted essentially this same patch over a year ago and Tom vetoed it: http://www.postgresql.org/message-id/3741.1325731...@sss.pgh.pa.us The thread moved to -hackers at some point and I made some further enhancements: http://www.postgresql.org/message-id/20120108201802.ga31...@llserver.lakeliving.com Never went anywhere though. -Ryan P. Kelly On Tue, May 05/14/13, 2013 at 11:35:36AM -0400, Peter Eisentraut wrote: Sometimes, the psql startup hangs when it cannot resolve or connect to a host. Intuitively, I would like to press Ctrl+C and correct the connection string or investigate. But that doesn't work because Ctrl+C is already bound to the query cancel handler by that time. It seems to me that there is no point in setting up the cancel handler before the database connection is established. Example patch attached. Comments? diff --git a/src/bin/psql/startup.c b/src/bin/psql/startup.c index 5d7fe6e..65a1cde 100644 --- a/src/bin/psql/startup.c +++ b/src/bin/psql/startup.c @@ -111,8 +111,6 @@ static void parse_psql_options(int argc, char *argv[], setvbuf(stderr, NULL, _IONBF, 0); #endif - setup_cancel_handler(); - pset.progname = get_progname(argv[0]); pset.db = NULL; @@ -249,6 +247,8 @@ static void parse_psql_options(int argc, char *argv[], exit(EXIT_BADCONN); } + setup_cancel_handler(); + PQsetNoticeProcessor(pset.db, NoticeProcessor, NULL); SyncVariables(); -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] psql connection reset failed
Hi, I tested this issue with 9.3beta1 , and same thing happening there too. By making changes as done in above patch, its work fine as expected. I am not sure, does this fixed is required to do? If so, then what should min wait time should set as 5000 microSec is seted for test, is this fine or too big? Is there any way to privide maxWaittime and minWaitTime, some other way by setting configuration parameters ? Thanks and regards, Amul Sul From: amul sul sul_a...@yahoo.co.in To: pgsql-hackers@postgresql.org pgsql-hackers@postgresql.org Sent: Friday, 10 May 2013 5:14 PM Subject: [HACKERS] psql connection reset failed I have observed the following situation a few times now , with 8.4.5. Multiple PSQL clients are connected to server, some of them running transaction and some of them are idle state. When one of the backend is killed or crashed (using kill -9 backend-pid). The connection reset attempt from the active clients( that is, which were running a transaction and crashed in between) fails, since they immediately make the attempt while the server is in startup phase. As you can see from following: --- ACTIVE CLIENT --- [amul@localhost ~]$ psql -p 5432 postgres psql (8.4.5) Type help for help. postgres=# create table emp( id int,name varchar(20)); CREATE TABLE postgres=# insert into emp values(generate_series(1,9),'XYZ'); WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. ! --- IDLE CLIENT --- [amul@localhost ~]$ psql -p 5432 postgres psql (8.4.5) Type help for help. postgres=# select pg_backend_pid(); server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Succeeded. postgres=# I just gone through and found following: 1. When backend crashes , server goes into recovery mode and come in the normal state to accept connection, it take little time. 2. But at busy client(which was running transaction before crash), immediately tries to reconnect to server which is under startup phase so it gets a negative reply and fails to reconnect. So I thought, before sending reconnect request from client need to wait for the server come to a state when it can accept connections It should have some timeout wait. I am not sure is this correct way to code modification or does it have any other impact. I tried wait to client before sending reconnect request to server. For that added some sleep time for client in src/bin/psql/common.c (that is it changes things only for psql clients) Please check the attached patch for the modification. -- 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] psql crash fix
On Tue, Apr 2, 2013 at 08:48:53PM -0400, Bruce Momjian wrote: I found that psql will crash if given a PSQLRC value containing a tilde: $ PSQLRC=~/x psql test *** glibc detected *** psql: free(): invalid pointer: 0x7fffb7c933ec *** This is on Debian Squeeze 6.0.7. The fix is to pstrdup() the value returned by getenv(), so it can be free()'ed later --- you can't free getenv()-returned values: As typically implemented, getenv() returns a pointer to a string within the environment list. The caller must take care not to modify this string, since that would change the environment of the process. This bug exists in 9.2 and git head. I also removed the return value from expand_tilde() as no caller was using it. Applied. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] psql \l to accept patterns
On Wed, 2013-01-30 at 00:20 +0900, Satoshi Nagayasu wrote: It seems working well with the latest git master. I think it's good enough to be committed. Committed, thanks. -- 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] psql \l to accept patterns
Hi, I have tried this patch. https://commitfest.postgresql.org/action/patch_view?id=1051 2013/01/29 14:48, Peter Eisentraut wrote: On Mon, 2013-01-07 at 07:14 -0500, Peter Eisentraut wrote: Here is a patch for psql's \l command to accept patterns, like \d commands do. While at it, I also added an S option to show system objects and removed system objects from the default display. This might be a bit controversial, but it's how it was decided some time ago that the \d commands should act. Most people didn't like the S option, so here is a revised patch that just adds the pattern support. It seems working well with the latest git master. I think it's good enough to be committed. BTW, is there any good place to put new regression test for the psql command? I couldn't find it out. Any comment or suggestion? Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- 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] psql \l to accept patterns
Satoshi Nagayasu sn...@uptime.jp writes: On Mon, 2013-01-07 at 07:14 -0500, Peter Eisentraut wrote: Here is a patch for psql's \l command to accept patterns, like \d BTW, is there any good place to put new regression test for the psql command? I couldn't find it out. As far as a test for this specific feature goes, I'd be against adding one, because it'd be likely to result in random failures in make installcheck mode, depending on what other databases are in the installation. More generally, we've tended to put tests of \d-style psql features together with the relevant backend-side tests. The proposed patch to add \gset adds a separate regression test file specifically for psql. I've been debating whether that was worth committing; but if there's near-term interest in adding any more tests for psql features that aren't closely connected to backend features, maybe it's worth having such a file. 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] psql \l to accept patterns
(2013/01/30 0:34), Tom Lane wrote: Satoshi Nagayasu sn...@uptime.jp writes: On Mon, 2013-01-07 at 07:14 -0500, Peter Eisentraut wrote: Here is a patch for psql's \l command to accept patterns, like \d BTW, is there any good place to put new regression test for the psql command? I couldn't find it out. As far as a test for this specific feature goes, I'd be against adding one, because it'd be likely to result in random failures in make installcheck mode, depending on what other databases are in the installation. More generally, we've tended to put tests of \d-style psql features together with the relevant backend-side tests. Yes, I think so too. First of all, I was looking for some regression tests for CREATE/ALTER/DROP DATABASE commands, but I couldn't find them in the test/regress/sql/ directory. So, I asked the question. I guess these database tests are in pg_regress.c. Right? The proposed patch to add \gset adds a separate regression test file specifically for psql. I've been debating whether that was worth committing; but if there's near-term interest in adding any more tests for psql features that aren't closely connected to backend features, maybe it's worth having such a file. Personally, I'm interested in having regression tests whatever the target is, because software tends to be more complicated. So, if we reach consensus to have dedicated tests for the psql command (or other client-side commands), I wish to contribute to it. Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- 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] psql \l to accept patterns
Satoshi Nagayasu sn...@uptime.jp writes: First of all, I was looking for some regression tests for CREATE/ALTER/DROP DATABASE commands, but I couldn't find them in the test/regress/sql/ directory. So, I asked the question. I guess these database tests are in pg_regress.c. Right? Yeah, we don't bother with explicit tests of CREATE/DROP DATABASE because that's inherently tested by creating/replacing the regression database(s). And these actions are expensive enough that I'm not eager to add several more of them to the test sequence without darn good reason. I'm not sure how much of ALTER DATABASE's functionality we're testing, though as you say pg_regress itself does some of that. It might be reasonable to add some more tests of ALTER cases. 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] psql \l to accept patterns
On Mon, 2013-01-07 at 07:14 -0500, Peter Eisentraut wrote:
Here is a patch for psql's \l command to accept patterns, like \d
commands do. While at it, I also added an S option to show system
objects and removed system objects from the default display. This might
be a bit controversial, but it's how it was decided some time ago that
the \d commands should act.
Most people didn't like the S option, so here is a revised patch that
just adds the pattern support.
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 4c87d8a..8d0095e 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -1689,12 +1689,13 @@ titleMeta-Commands/title
varlistentry
-termliteral\l/literal (or literal\list/literal)/term
-termliteral\l+/literal (or literal\list+/literal)/term
+termliteral\l[+]/literal or literal\list[+]/literal/term
listitem
para
-List the names, owners, character set encodings, and access privileges
-of all the databases in the server.
+List the databases in the server and show their names, owners,
+character set encodings, and access privileges.
+If replaceable class=parameterpattern/replaceable is specified,
+only databases whose names match the pattern are listed.
If literal+/literal is appended to the command name, database
sizes, default tablespaces, and descriptions are also displayed.
(Size information is only available for databases that the current
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 20c45e2..e40f8b2 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -804,10 +804,22 @@ static bool do_edit(const char *filename_arg, PQExpBuffer query_buf,
}
/* \l is list databases */
- else if (strcmp(cmd, l) == 0 || strcmp(cmd, list) == 0)
- success = listAllDbs(false);
- else if (strcmp(cmd, l+) == 0 || strcmp(cmd, list+) == 0)
- success = listAllDbs(true);
+ else if (strcmp(cmd, l) == 0 || strcmp(cmd, list) == 0 ||
+ strcmp(cmd, l+) == 0 || strcmp(cmd, list+) == 0)
+ {
+ char *pattern;
+ bool show_verbose;
+
+ pattern = psql_scan_slash_option(scan_state,
+ OT_NORMAL, NULL, true);
+
+ show_verbose = strchr(cmd, '+') ? true : false;
+
+ success = listAllDbs(pattern, show_verbose);
+
+ if (pattern)
+ free(pattern);
+ }
/*
* large object things
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index 8064a3d..046513d 100644
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -641,7 +641,7 @@ static bool describeOneTSConfig(const char *oid, const char *nspname,
* for \l, \list, and -l switch
*/
bool
-listAllDbs(bool verbose)
+listAllDbs(const char *pattern, bool verbose)
{
PGresult *res;
PQExpBufferData buf;
@@ -684,6 +684,11 @@ static bool describeOneTSConfig(const char *oid, const char *nspname,
if (verbose pset.sversion = 8)
appendPQExpBuffer(buf,
JOIN pg_catalog.pg_tablespace t on d.dattablespace = t.oid\n);
+
+ if (pattern)
+ processSQLNamePattern(pset.db, buf, pattern, false, false,
+ NULL, d.datname, NULL, NULL);
+
appendPQExpBuffer(buf, ORDER BY 1;);
res = PSQLexec(buf.data, false);
termPQExpBuffer(buf);
diff --git a/src/bin/psql/describe.h b/src/bin/psql/describe.h
index 9e71a88..09b6237 100644
--- a/src/bin/psql/describe.h
+++ b/src/bin/psql/describe.h
@@ -55,7 +55,7 @@ extern bool listTSDictionaries(const char *pattern, bool verbose);
extern bool listTSTemplates(const char *pattern, bool verbose);
/* \l */
-extern bool listAllDbs(bool verbose);
+extern bool listAllDbs(const char *pattern, bool verbose);
/* \dt, \di, \ds, \dS, etc. */
extern bool listTables(const char *tabtypes, const char *pattern, bool verbose, bool showSystem);
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index fd7effa..2cbdd83 100644
--- a/src/bin/psql/help.c
+++ b/src/bin/psql/help.c
@@ -233,7 +233,7 @@
fprintf(output, _( \\dE[S+] [PATTERN] list foreign tables\n));
fprintf(output, _( \\dx[+] [PATTERN] list extensions\n));
fprintf(output, _( \\dy [PATTERN] list event triggers\n));
- fprintf(output, _( \\l[+] list all databases\n));
+ fprintf(output, _( \\l[+] [PATTERN] list databases\n));
fprintf(output, _( \\sf[+] FUNCNAMEshow a function's definition\n));
fprintf(output, _( \\z [PATTERN] same as \\dp\n));
fprintf(output, \n);
diff --git a/src/bin/psql/startup.c b/src/bin/psql/startup.c
index a59f45b..5cb6b5f 100644
--- a/src/bin/psql/startup.c
+++ b/src/bin/psql/startup.c
@@ -260,7 +260,7 @@ static void parse_psql_options(int argc, char *argv[],
if (!options.no_psqlrc)
process_psqlrc(argv[0]);
- success = listAllDbs(false);
+ success = listAllDbs(NULL, false);
PQfinish(pset.db);
exit(success ? EXIT_SUCCESS : EXIT_FAILURE);
}
--
Sent via pgsql-hackers mailing list
Re: [HACKERS] psql: small patch to correct filename formatting error in '\s FILE' output
Ian Lawrence Barwick barw...@gmail.com writes: I've noticed a filename error in feedback messages from psql's '\s' command when saving the command line history to a file specified by an absolute filepath: psql (9.2.2) Type help for help. pgdevel=# \s history.txt Wrote history to file ./history.txt. pgdevel=# \s /tmp/history.txt Wrote history to file .//tmp/history.txt. pgdevel=# \cd /tmp pgdevel=# \s /tmp/history.txt Wrote history to file /tmp//tmp/history.txt. The second and third '\s' commands display incorrect filepaths in the feedback message, despite writing correctly to the specified file. I wonder why we don't just revert commit 0725065b --- this complaint shows that it was quite poorly thought out, and I don't really see the need for it anyway. Aside from the complained-of bug, the code added to the \cd command is entirely incapable of tracking through multiple \cd operations properly. If we did think that this specific backslash command needed to be able to print something other than the filename as-entered, I'd be inclined to just apply make_absolute_path() to the name, instead of relying on inadequate dead-reckoning. However, that would require making make_absolute_path available in src/port/ or someplace, which seems a bit more than this feature is worth. Why should \s, and \s alone, need to remind you where you're cd'd to? Thoughts? 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] psql: small patch to correct filename formatting error in '\s FILE' output
2013/1/22 Tom Lane t...@sss.pgh.pa.us: Why should \s, and \s alone, need to remind you where you're cd'd to? Why not just get rid of that prefixed cd'd path in \s? []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br -- 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] psql: small patch to correct filename formatting error in '\s FILE' output
I wrote: If we did think that this specific backslash command needed to be able to print something other than the filename as-entered, I'd be inclined to just apply make_absolute_path() to the name, instead of relying on inadequate dead-reckoning. However, that would require making make_absolute_path available in src/port/ or someplace, which seems a bit more than this feature is worth. Why should \s, and \s alone, need to remind you where you're cd'd to? It strikes me that a more useful reminder feature could be implemented by having \cd itself print the new current directory, which it could do with a simple call to getcwd(), thus not requiring refactoring of make_absolute_path. Then for instance if you'd forgotten where you were, \cd . would tell you. 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] psql: small patch to correct filename formatting error in '\s FILE' output
2013/1/23 Tom Lane t...@sss.pgh.pa.us: I wrote: If we did think that this specific backslash command needed to be able to print something other than the filename as-entered, I'd be inclined to just apply make_absolute_path() to the name, instead of relying on inadequate dead-reckoning. However, that would require making make_absolute_path available in src/port/ or someplace, which seems a bit more than this feature is worth. Why should \s, and \s alone, need to remind you where you're cd'd to? It strikes me that a more useful reminder feature could be implemented by having \cd itself print the new current directory, which it could do with a simple call to getcwd(), thus not requiring refactoring of make_absolute_path. Then for instance if you'd forgotten where you were, \cd . would tell you. \! pwd does the trick as well. However personally I prefer to get some kind of feedback from an action, so having \cd confirm the directory would be nice. I'll submit a patch. Related email from the archives on this subject: http://www.postgresql.org/message-id/37ed240d0611200645l5b70c8ddw5fb735e0d35a7...@mail.gmail.com Does commit 0725065b just need to be reverted, or is an additional patch required to remove the prefixed working directory from \s output? Ian Barwick -- 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] psql: small patch to correct filename formatting error in '\s FILE' output
Ian Lawrence Barwick barw...@gmail.com writes: Related email from the archives on this subject: http://www.postgresql.org/message-id/37ed240d0611200645l5b70c8ddw5fb735e0d35a7...@mail.gmail.com I agree with the opinion stated there that \cd with no argument really ought to do what cd with no argument usually does on the platform. So if we're going to fix \cd to print the resulting current directory, wouldn't it work to just set dir to . rather than / for Windows? Does commit 0725065b just need to be reverted, or is an additional patch required to remove the prefixed working directory from \s output? Offhand it looked like reverting the commit would be enough, but I didn't look hard to see if there had been any subsequent related changes. [ pokes around... ] Well, at least there are still no other uses of pset.dirname. 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] psql \l to accept patterns
On Tue, Jan 8, 2013 at 11:36 PM, Peter Eisentraut pete...@gmx.net wrote: On Mon, 2013-01-07 at 17:37 -0500, Robert Haas wrote: If we make the postgres database undroppable, unrenamable, and strictly read-only, I will happily support a proposal to consider it a system object. Until then, it's no more a system object than the public schema - which, you will note, \dn has no compunctions about displaying, even without S. Good point. What about the other suggestion about only displaying databases by default that you can connect to? I would tend not to adopt that suggestion, on the grounds that it has no obvious parallel with anything else psql hides by default. However, I don't feel quite as strongly about that case. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] psql \l to accept patterns
* Robert Haas (robertmh...@gmail.com) wrote: On Tue, Jan 8, 2013 at 11:36 PM, Peter Eisentraut pete...@gmx.net wrote: Good point. What about the other suggestion about only displaying databases by default that you can connect to? I would tend not to adopt that suggestion, on the grounds that it has no obvious parallel with anything else psql hides by default. However, I don't feel quite as strongly about that case. In the past, haven't we done this through the catalog tables themselves rather than hacking up psql..? pg_stats being a prime example? With the row-level-security discussion, there was talk about if we might be able to apply that capability to catalogs also. That strikes me as a better option/approach than doing any of this in one particular application (psql in this case) which connects to PG. tbh, I'm not entirely against excluding databases that don't allow *any* connections (key'd off datallowconns) to clear out template0/template1 from the default list, but I see that as different from things I don't have permissions to. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] psql \l to accept patterns
On Mon, 2013-01-07 at 17:37 -0500, Robert Haas wrote: If we make the postgres database undroppable, unrenamable, and strictly read-only, I will happily support a proposal to consider it a system object. Until then, it's no more a system object than the public schema - which, you will note, \dn has no compunctions about displaying, even without S. Good point. What about the other suggestion about only displaying databases by default that you can connect to? -- 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] psql \l to accept patterns
On Mon, Jan 7, 2013 at 10:14 AM, Peter Eisentraut pete...@gmx.net wrote: Here is a patch for psql's \l command to accept patterns, like \d commands do. While at it, I also added an S option to show system objects and removed system objects from the default display. This might be a bit controversial, but it's how it was decided some time ago that the \d commands should act. I applied the attached patch to the current master branch and everything is ok. When build all works fine too... and I do some tests: 1) Now '\l' list only regular databases postgres=# \l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges --+---+--+-+---+--- (0 rows) postgres=# CREATE DATABASE fabrizio; CREATE DATABASE postgres=# \l List of databases Name | Owner | Encoding | Collate |Ctype| Access privileges --+--+--+-+-+--- fabrizio | fabrizio | UTF8 | en_US.UTF-8 | en_US.UTF-8 | (1 row) postgres=# \l+ List of databases Name | Owner | Encoding | Collate |Ctype| Access privileges | Size | Tablespace | Description --+--+--+-+-+---+-++- fabrizio | fabrizio | UTF8 | en_US.UTF-8 | en_US.UTF-8 | | 5945 kB | pg_default | (1 row) postgres=# DROP DATABASE fabrizio; DROP DATABASE postgres=# \l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges --+---+--+-+---+--- (0 rows) 2) The new sub-command '\lS' list regular and systems databases postgres=# \lS List of databases Name| Owner | Encoding | Collate |Ctype| Access privileges ---+--+--+-+-+--- postgres | fabrizio | UTF8 | en_US.UTF-8 | en_US.UTF-8 | template0 | fabrizio | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/fabrizio + | | | | | fabrizio=CTc/fabrizio template1 | fabrizio | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/fabrizio + | | | | | fabrizio=CTc/fabrizio (3 rows) postgres=# CREATE DATABASE fabrizio; CREATE DATABASE postgres=# \lS List of databases Name| Owner | Encoding | Collate |Ctype| Access privileges ---+--+--+-+-+--- fabrizio | fabrizio | UTF8 | en_US.UTF-8 | en_US.UTF-8 | postgres | fabrizio | UTF8 | en_US.UTF-8 | en_US.UTF-8 | template0 | fabrizio | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/fabrizio + | | | | | fabrizio=CTc/fabrizio template1 | fabrizio | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/fabrizio + | | | | | fabrizio=CTc/fabrizio (4 rows) postgres=# \lS+ List of databases Name| Owner | Encoding | Collate |Ctype| Access privileges | Size | Tablespace |Description ---+--+--+-+-+---+-++ fabrizio | fabrizio | UTF8 | en_US.UTF-8 | en_US.UTF-8 | | 5945 kB | pg_default | postgres | fabrizio | UTF8 | en_US.UTF-8 | en_US.UTF-8 | | 6041 kB | pg_default | default administrative connecti on database template0 | fabrizio | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/fabrizio +| 5945 kB | pg_default | unmodifiable empty database | | | | | fabrizio=CTc/fabrizio | || template1 | fabrizio | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/fabrizio +| 5945 kB | pg_default | default template for new databa ses | | | | | fabrizio=CTc/fabrizio | || (4 rows) postgres=# DROP DATABASE fabrizio ; DROP DATABASE postgres=# \lS List of databases Name| Owner | Encoding | Collate |Ctype| Access privileges ---+--+--+-+-+--- postgres | fabrizio | UTF8 | en_US.UTF-8 | en_US.UTF-8 | template0 | fabrizio | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/fabrizio + | | | | | fabrizio=CTc/fabrizio template1 | fabrizio | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/fabrizio
Re: [HACKERS] psql \l to accept patterns
Peter Eisentraut wrote: Here is a patch for psql's \l command to accept patterns, like \d commands do. While at it, I also added an S option to show system objects and removed system objects from the default display. This might be a bit controversial, but it's how it was decided some time ago that the \d commands should act. How does this affect psql -l? Should it, for instance, hide system DBs? Accept an optional pattern? -- Álvaro Herrerahttp://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] psql \l to accept patterns
On Mon, Jan 7, 2013 at 7:14 AM, Peter Eisentraut pete...@gmx.net wrote: Here is a patch for psql's \l command to accept patterns, like \d commands do. While at it, I also added an S option to show system objects and removed system objects from the default display. This might be a bit controversial, but it's how it was decided some time ago that the \d commands should act. -1 from me on that last bit. I don't think that you can really compare the postgres or template1 database to, say, the pg_toast schema. There's no real reason for people to ever care about objects in the pg_toast schema, but the same cannot be said about template1, which it's often necessary to connect to when running many of the commands (vacuumdb -a, etc.) we ship with our distribution. I think this will just be confusing to users without any real upside. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] psql \l to accept patterns
Robert Haas robertmh...@gmail.com writes: On Mon, Jan 7, 2013 at 7:14 AM, Peter Eisentraut pete...@gmx.net wrote: Here is a patch for psql's \l command to accept patterns, like \d commands do. While at it, I also added an S option to show system objects and removed system objects from the default display. This might be a bit controversial, but it's how it was decided some time ago that the \d commands should act. -1 from me on that last bit. I don't think that you can really compare the postgres or template1 database to, say, the pg_toast schema. There's no real reason for people to ever care about objects in the pg_toast schema, but the same cannot be said about template1, which it's often necessary to connect to when running many of the commands (vacuumdb -a, etc.) we ship with our distribution. I think this will just be confusing to users without any real upside. Suppressing the postgres DB is even worse. I think that it might be sensible to have an S option and define system DBs as those without datallowconn, which ordinarily would only hide template0. But I can't get real excited about that. People do need to know about the existence of template0 (for use in CREATE DATABASE ... TEMPLATE ...), which is not so true of, say, pg_temp_NNN schemas. The it reduces clutter argument also seems pretty weak if we're only hiding one database, or even three of them. On the whole I lean towards not adding this notion. 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] psql \l to accept patterns
On 1/7/13 3:53 PM, Robert Haas wrote: On Mon, Jan 7, 2013 at 7:14 AM, Peter Eisentraut pete...@gmx.net wrote: Here is a patch for psql's \l command to accept patterns, like \d commands do. While at it, I also added an S option to show system objects and removed system objects from the default display. This might be a bit controversial, but it's how it was decided some time ago that the \d commands should act. -1 from me on that last bit. I don't think that you can really compare the postgres or template1 database to, say, the pg_toast schema. There's no real reason for people to ever care about objects in the pg_toast schema, but the same cannot be said about template1, which it's often necessary to connect to when running many of the commands (vacuumdb -a, etc.) we ship with our distribution. I think this will just be confusing to users without any real upside. We removed showing system functions and operators from \df and \do without S. Those are needed all the time. This was controversial at the time, but it's the way it is now. The definition of S, I suppose, is more like is there after database is created, not typical users care about these objects. -- 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] psql \l to accept patterns
On Mon, Jan 7, 2013 at 5:14 PM, Peter Eisentraut pete...@gmx.net wrote: We removed showing system functions and operators from \df and \do without S. Those are needed all the time. This was controversial at the time, but it's the way it is now. The definition of S, I suppose, is more like is there after database is created, not typical users care about these objects. System functions and operators are needed all the time, but so are system tables and views, and the old behavior was that the latter were suppressed by default and the former were included by default. So I consider that change to be well-justified on consistency grounds. There's a practical consideration, as well. Out of the box, there are 2400 entries for functions and 3 for databases. This means that the old \df behavior made it very hard to figure out what user-defined functions exist in your database, but there's no corresponding problem with \l. Finally, note that you can drop the postgres database (and everything else will still work) but you cannot drop pg_table_is_visible(oid), because, as the error message will inform you, it is required by the database system. If we make the postgres database undroppable, unrenamable, and strictly read-only, I will happily support a proposal to consider it a system object. Until then, it's no more a system object than the public schema - which, you will note, \dn has no compunctions about displaying, even without S. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] psql, remove include of psqlscan.c
Karl O. Pinc k...@meme.com writes: This patch (psql_remove_include.patch) eliminates the #include of psqlscan.c at the bottom of mainloop.c. I don't really see that this is enough of an improvement to justify depending on a non-portable flex feature. I'm thinking of exposing enough of the psql parser, moving it to libpq, that any client-side app can do what libpq does; given a bunch of sql separated by semi-colons get the results of all the statements. This should also allow the statement separation to be done on the client side in libpq. Although I don't imagine that this will have a performance impact on the server side it sounds like a first step toward pushing more of the parsing onto the client. Quite honestly, I don't like that idea at all either. It's bad enough that psql has to know so much low-level SQL syntax. If we start encouraging other programs to know that, we're going to be locked into never again making any lexical-level changes. Why exactly is pushing parsing onto the client a good idea? 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] psql, remove include of psqlscan.c
On 09/27/2012 10:07:48 AM, Tom Lane wrote: Karl O. Pinc k...@meme.com writes: This patch (psql_remove_include.patch) eliminates the #include of psqlscan.c at the bottom of mainloop.c. I don't really see that this is enough of an improvement to justify depending on a non-portable flex feature. Ok. (I had no idea it was non-portable. The flex docs don't mention this.) I'm thinking of exposing enough of the psql parser, moving it to libpq, that any client-side app can do what libpq does; given a bunch of sql separated by semi-colons get the results of all the statements. This should also allow the statement separation to be done on the client side in libpq. Although I don't imagine that this will have a performance impact on the server side it sounds like a first step toward pushing more of the parsing onto the client. Quite honestly, I don't like that idea at all either. It's bad enough that psql has to know so much low-level SQL syntax. If we start encouraging other programs to know that, we're going to be locked into never again making any lexical-level changes. Why exactly is pushing parsing onto the client a good idea? There's really 2 ideas. I don't care about this one: pushing parsing/anything onto the client is a good idea because clients scale horizontally and so performance is improved. What I'm thinking of in libpq is the ability to give it big string with many sql statements and have it hand back each statement so the client can then submit it to the server for execution. What I really _want_ is to be able get a bit string of many sql statements from the user and return the results, statuses, etc. of executing each statement. Just what psql does when, say, fed a file from stdin. The reason I want this is because I don't want to have to rewrite the sql parser in PHP for inclusion in phpPgAdmin. (I did this once, and it was such a big ugly patch it never got around to getting into the mainline phpPgAdmin.) phpPgAdmin (pgAdmin/ front-end of your choice) should be able process a string of sql statements in the same way that psql does, but currently the only way to do this is to rewrite the parser in each application. Much better to have libpq provide the functionality, although I suppose it's possible to push this into the server. Karl k...@meme.com Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein -- 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] psql, remove include of psqlscan.c
Excerpts from Karl O. Pinc's message of jue sep 27 12:29:53 -0300 2012: The reason I want this is because I don't want to have to rewrite the sql parser in PHP for inclusion in phpPgAdmin. (I did this once, and it was such a big ugly patch it never got around to getting into the mainline phpPgAdmin.) phpPgAdmin (pgAdmin/ front-end of your choice) should be able process a string of sql statements in the same way that psql does, but currently the only way to do this is to rewrite the parser in each application. Much better to have libpq provide the functionality, although I suppose it's possible to push this into the server. This seems a worthy goal to me. But I think I see what Tom objection to it is: if we export this capability to libpq applications, then we set it in stone to a certain extent: exactly how things are split would become part of the API, so to speak. Upgrading to a newer libpq could break application code that worked with the previous release's by splitting things differently. I don't currently have an opinion on whether this is a bad thing or not. Who wants to argue for/against? -- Álvaro Herrerahttp://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] psql, remove include of psqlscan.c
On 09/27/12 8:41 AM, Alvaro Herrera wrote: But I think I see what Tom objection to it is: if we export this capability to libpq applications, then we set it in stone to a certain extent: exactly how things are split would become part of the API, so to speak. Upgrading to a newer libpq could break application code that worked with the previous release's by splitting things differently. I don't currently have an opinion on whether this is a bad thing or not. Who wants to argue for/against? I wonder if it shouldn't be in a separate 'helper' library, as it has no direct ties to any libpq internals. -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- 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] psql, remove include of psqlscan.c
Alvaro Herrera alvhe...@2ndquadrant.com writes: But I think I see what Tom objection to it is: if we export this capability to libpq applications, then we set it in stone to a certain extent: exactly how things are split would become part of the API, so to speak. Upgrading to a newer libpq could break application code that worked with the previous release's by splitting things differently. That's not exactly what the problem is: an upgrade could only break *existing* application code if we had made a non-backward-compatible change in SQL lexical rules, which hopefully we'd never do. Rather, the problem is that the server might know about some newer lexical feature, and so might the application, but if libpq is behind the times then it's broken. You can see an instance of this right now over in the pgsql-jdbc list, where they're arguing about fixing the JDBC driver to understand dollar quoting. Application authors not unreasonably think it should have heard of that by now. The JDBC example is sort of an argument in favor of Karl's idea, in that if client-side code is going to know this anyway then it would be better if it were at least localized in one place. But of course JDBC is never going to depend on libpq (wrong language) so moving this code into libpq isn't actually going to help them. A larger point is that I don't believe this is actually going to help anybody, because of mismatch of requirements not only implementation language. JDBC couldn't use a libpq lexer implementation even without the language issue, because the context in which they're arguing about this is finding and replacing JDBC-spec escape sequences, which libpq is not going to know about. I imagine PHP has got the same problem only different. Conversely, psql's lexer has a lot of psql-specific design decisions, such as the need to handle backslash commands and include files, that I don't think would belong in a libpq implementation. 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] psql, remove include of psqlscan.c
On 09/27/2012 11:02:42 AM, Tom Lane wrote: Alvaro Herrera alvhe...@2ndquadrant.com writes: A larger point is that I don't believe this is actually going to help anybody, because of mismatch of requirements not only implementation language. JDBC couldn't use a libpq lexer implementation even without the language issue, because the context in which they're arguing about this is finding and replacing JDBC-spec escape sequences, which libpq is not going to know about. I imagine PHP has got the same problem only different. Conversely, psql's lexer has a lot of psql-specific design decisions, such as the need to handle backslash commands and include files, that I don't think would belong in a libpq implementation. Well no, I'm not at all interested in escape sequences. I want to take sql directly from the user and execute it. Right now I can take only one statement at a time. And this is true of any human-facing application. I'm not looking for a general purpose solution, although it did occur to me that the psql variable substitution mechanism could be exposed. But what I really want is not an exposed parser. What I really want is to be able to get results from all the statements passed to PQexec (et-al), not just the last statement. This could be done without exposing the parser, but it does mean having a parser in libpq. Since psql links to libpq anyway my plan was to move the parser entirely out of psql into libpq and have an undocumented internal interface so that psql can do the escaping/variable substitution stuff. Regards, Karl k...@meme.com Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein -- 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] psql, remove include of psqlscan.c
On 09/27/2012 11:02:42 AM, Tom Lane wrote: Rather, the problem is that the server might know about some newer lexical feature, and so might the application, but if libpq is behind the times then it's broken. If the application knows about the newer feature and wants to use it, is it unreasonable to ask the application be linked against a newer libpq? Karl k...@meme.com Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein -- 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] psql, remove include of psqlscan.c
Karl O. Pinc k...@meme.com writes: What I'm thinking of in libpq is the ability to give it big string with many sql statements and have it hand back each statement so the client can then submit it to the server for execution. What I really _want_ is to be able get a bit string of many sql statements from the user and return the results, statuses, etc. of executing each statement. Just what psql does when, say, fed a file from stdin. Just as a note --- I believe you can get that result today with PQsendQuery followed by a PQgetResult loop. There's no need to provide an API that splits the string first. 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] psql, remove include of psqlscan.c
Karl O. Pinc k...@meme.com writes: On 09/27/2012 11:02:42 AM, Tom Lane wrote: Rather, the problem is that the server might know about some newer lexical feature, and so might the application, but if libpq is behind the times then it's broken. If the application knows about the newer feature and wants to use it, is it unreasonable to ask the application be linked against a newer libpq? Well, see the JDBC example: there is no newer driver with the desired feature for applications to link against. Even if all client-side code with such knowledge stays perfectly in sync as far as upstream sources are concerned, there are any number of reasons why particular installations might have copies of varying vintages. It's not really a situation that I want to get into more than necessary. 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] psql, remove include of psqlscan.c
On 09/27/2012 02:28:49 PM, Tom Lane wrote: Karl O. Pinc k...@meme.com writes: What I really _want_ is to be able get a bit string of many sql statements from the user and return the results, statuses, etc. of executing each statement. Just what psql does when, say, fed a file from stdin. Just as a note --- I believe you can get that result today with PQsendQuery followed by a PQgetResult loop. There's no need to provide an API that splits the string first. Ah. *sigh* I should pay better attention. Sorry for the distraction. Karl k...@meme.com Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein -- 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] psql: tab-completion fails SET var=
On Fri, Mar 30, 2012 at 08:15:22PM +0200, Erik Rijkers wrote:
(in hopes that the current changes to tab-completion will help to get this
fixed)
tab-completion goes wrong on SET setting=...
example:
If you want to input set search_path=myschema; without spaces around '=',
and you try tab-completion halfway the schemaname:
set search_path=mysch
^tab
then the initial part of the schema name ('mysch') gets removed and replaced
with 'TO'.
So that you now have:
set search_path=TO cursor
You lose the part of the schema name that was already input.
With spaces that doesn't happen, but after all tabcompletion is about
avoiding keystrokes and errors.
Tab-completion is great and this search_path-annoyance happens to me all the
time; my fingers
can't seem to learn this exception.
(pgsql 9.2devel, problem also in latest 9.1.3)
I have fixed this with the attached patch. It does not do any further
competion of DEFAULT or other known settings if the equal sign has no
space before it.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
new file mode 100644
index 8a74877..bfba1dd
*** a/src/bin/psql/tab-complete.c
--- b/src/bin/psql/tab-complete.c
*** psql_completion(char *text, int start, i
*** 2842,2847
--- 2842,2848
pg_strcasecmp(prev_wd, TABLESPACE) != 0
pg_strcasecmp(prev_wd, SCHEMA) != 0
prev_wd[strlen(prev_wd) - 1] != ')'
+ prev_wd[strlen(prev_wd) - 1] != '='
pg_strcasecmp(prev4_wd, DOMAIN) != 0)
COMPLETE_WITH_CONST(TO);
/* Suggest possible variable values */
--
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] psql \set vs \copy - bug or expected behaviour?
On Fri, Aug 17, 2012 at 02:01:25PM -0400, Bruce Momjian wrote:
On Fri, Aug 17, 2012 at 06:55:14PM +0100, Richard Huxton wrote:
Well, it'd be nice to allow substitution there ...
What we can't easily do is to allow quotes to prevent variable
substitution in these whole-line commands because we can't process the
quotes because that will remove them.
... but if there is then no way to prevent it, that's absolutely
unacceptable.
If I'm understanding this correctly, \copy parsing just passes the
query part unaltered as part of a COPY statement back into the
top-level parser. Likewise with the \!shell stuff (but presumably to
execve).
To handle variable-substitution correctly for \copy we'd need to
duplicate the full parsing for COPY. For \! we'd need something
which understood shell-syntax (for the various shells out there).
Ick.
Or you'd need a separate variable-bracketing {{:x}} syntax that
could work like reverse dollar-quoting. Also Ick.
As far as we know this has only inconvenienced one person (me) badly
enough to report a maybe-bug. Thanks for trying Bruce, but I fear
this is one itch that'll go unscratched.
Rest assured I'm not about to storm off and replace all my
installations with MySQL :-)
Good analysis. Basically we can't hope to fully understand COPY or
shell quoting syntax well enough to properly replace only unquoted psql
variable references.
Therefore, unless I hear otherwise, I will just document the limitation
and withdraw the patch.
Patch withdrawn. Seems documentation was already in place --- I
clarified \! limitations match \copy.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
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] psql output locations
On Fri, Aug 17, 2012 at 12:28:58PM -0400, Bruce Momjian wrote: On Fri, Aug 17, 2012 at 12:22:38PM -0400, Alvaro Herrera wrote: Excerpts from Bruce Momjian's message of vie ago 17 11:17:58 -0400 2012: On Wed, Dec 14, 2011 at 10:57:25AM -0500, Robert Haas wrote: On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander mag...@hagander.net wrote: * There are a number of things that are always written to stdout, that there is no way to redirect. In some cases it's interactive prompts - makes sense - but also for example the output of \timing goes to stdout always. Is there some specific logic behind what/when this should be done? Everything that is not an error goes to stdout, no? Except the query output, if you change it. Maybe the way to do what you want is to invent a new setting that temporarily changes stdout. Yeah, that might be it. Or I need separate settings for put errors in the query output stream and put non-query-output-but-also-non-errors in the query output stream. The effect would be the same, I guess... That seems an awful lot harder (and messier) than just changing the all the call sites to use the same error-reporting function. I have done as you suggested with the attached patch. The very first hunk in your patch changes code that seems to be explicitely checking the interactive flag. Is the change really wanted there? Note Magnus explicitely commented about those in his original post. I noticed that but the output would be the same because there is no input file location to trigger. I thought the interactive flag was there just to provide more customized text. Applied. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] psql output locations
On Wed, Dec 14, 2011 at 10:57:25AM -0500, Robert Haas wrote:
On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander mag...@hagander.net wrote:
* There are a number of things that are always written to stdout, that
there is no way to redirect. In some cases it's interactive prompts -
makes sense - but also for example the output of \timing goes to
stdout always. Is there some specific logic behind what/when this
should be done?
Everything that is not an error goes to stdout, no? Except the query
output, if you change it.
Maybe the way to do what you want is to invent a new setting that
temporarily changes stdout.
Yeah, that might be it. Or I need separate settings for put errors in
the query output stream and put non-query-output-but-also-non-errors
in the query output stream. The effect would be the same, I guess...
That seems an awful lot harder (and messier) than just changing the
all the call sites to use the same error-reporting function.
I have done as you suggested with the attached patch.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
new file mode 100644
index 205bb50..dc04399
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
*** HandleSlashCmds(PsqlScanState scan_state
*** 110,116
if (status == PSQL_CMD_UNKNOWN)
{
if (pset.cur_cmd_interactive)
! fprintf(stderr, _(Invalid command \\%s. Try \\? for help.\n), cmd);
else
psql_error(invalid command \\%s\n, cmd);
status = PSQL_CMD_ERROR;
--- 110,116
if (status == PSQL_CMD_UNKNOWN)
{
if (pset.cur_cmd_interactive)
! psql_error(Invalid command \\%s. Try \\? for help.\n, cmd);
else
psql_error(invalid command \\%s\n, cmd);
status = PSQL_CMD_ERROR;
*** exec_command(const char *cmd,
*** 904,910
if (strcmp(pw1, pw2) != 0)
{
! fprintf(stderr, _(Passwords didn't match.\n));
success = false;
}
else
--- 904,910
if (strcmp(pw1, pw2) != 0)
{
! psql_error(Passwords didn't match.\n);
success = false;
}
else
*** exec_command(const char *cmd,
*** 922,928
if (!encrypted_password)
{
! fprintf(stderr, _(Password encryption failed.\n));
success = false;
}
else
--- 922,928
if (!encrypted_password)
{
! psql_error(Password encryption failed.\n);
success = false;
}
else
*** exec_command(const char *cmd,
*** 1441,1447
while ((value = psql_scan_slash_option(scan_state,
OT_NORMAL, NULL, true)))
{
! fprintf(stderr, + opt(%d) = |%s|\n, i++, value);
free(value);
}
}
--- 1441,1447
while ((value = psql_scan_slash_option(scan_state,
OT_NORMAL, NULL, true)))
{
! psql_error(+ opt(%d) = |%s|\n, i++, value);
free(value);
}
}
*** do_connect(char *dbname, char *user, cha
*** 1519,1525
* to connect to the wrong database by using defaults, so require
* all parameters to be specified.
*/
! fputs(_(All connection parameters must be supplied because no database connection exists\n), stderr);
return false;
}
--- 1519,1526
* to connect to the wrong database by using defaults, so require
* all parameters to be specified.
*/
! psql_error(All connection parameters must be supplied because no
! database connection exists\n);
return false;
}
*** do_connect(char *dbname, char *user, cha
*** 1608,1614
/* pset.db is left unmodified */
if (o_conn)
! fputs(_(Previous connection kept\n), stderr);
}
else
{
--- 1609,1615
/* pset.db is left unmodified */
if (o_conn)
! psql_error(Previous connection kept\n);
}
else
{
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
new file mode 100644
index 330d5ce..f5bd0f6
*** a/src/bin/psql/common.c
--- b/src/bin/psql/common.c
*** pg_strdup(const char *string)
*** 42,48
if (!string)
{
! fprintf(stderr, _(%s: pg_strdup: cannot duplicate null pointer (internal error)\n),
pset.progname);
exit(EXIT_FAILURE);
}
--- 42,48
if (!string)
{
! psql_error(%s: pg_strdup: cannot duplicate null pointer (internal error)\n,
pset.progname);
exit(EXIT_FAILURE);
}
*** psql_error(const char *fmt,...)
*** 161,167
va_list ap;
fflush(stdout);
! if (pset.queryFout != stdout)
fflush(pset.queryFout);
if (pset.inputfile)
--- 161,167
va_list ap;
fflush(stdout);
! if (pset.queryFout pset.queryFout != stdout)
fflush(pset.queryFout);
if (pset.inputfile)
*** static PGcancel *volatile cancelConn = N
*** 219,224
--- 219,225
Re: [HACKERS] psql output locations
Excerpts from Bruce Momjian's message of vie ago 17 11:17:58 -0400 2012: On Wed, Dec 14, 2011 at 10:57:25AM -0500, Robert Haas wrote: On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander mag...@hagander.net wrote: * There are a number of things that are always written to stdout, that there is no way to redirect. In some cases it's interactive prompts - makes sense - but also for example the output of \timing goes to stdout always. Is there some specific logic behind what/when this should be done? Everything that is not an error goes to stdout, no? Except the query output, if you change it. Maybe the way to do what you want is to invent a new setting that temporarily changes stdout. Yeah, that might be it. Or I need separate settings for put errors in the query output stream and put non-query-output-but-also-non-errors in the query output stream. The effect would be the same, I guess... That seems an awful lot harder (and messier) than just changing the all the call sites to use the same error-reporting function. I have done as you suggested with the attached patch. The very first hunk in your patch changes code that seems to be explicitely checking the interactive flag. Is the change really wanted there? Note Magnus explicitely commented about those in his original post. -- Álvaro Herrerahttp://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] psql output locations
On Fri, Aug 17, 2012 at 12:22:38PM -0400, Alvaro Herrera wrote: Excerpts from Bruce Momjian's message of vie ago 17 11:17:58 -0400 2012: On Wed, Dec 14, 2011 at 10:57:25AM -0500, Robert Haas wrote: On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander mag...@hagander.net wrote: * There are a number of things that are always written to stdout, that there is no way to redirect. In some cases it's interactive prompts - makes sense - but also for example the output of \timing goes to stdout always. Is there some specific logic behind what/when this should be done? Everything that is not an error goes to stdout, no? Except the query output, if you change it. Maybe the way to do what you want is to invent a new setting that temporarily changes stdout. Yeah, that might be it. Or I need separate settings for put errors in the query output stream and put non-query-output-but-also-non-errors in the query output stream. The effect would be the same, I guess... That seems an awful lot harder (and messier) than just changing the all the call sites to use the same error-reporting function. I have done as you suggested with the attached patch. The very first hunk in your patch changes code that seems to be explicitely checking the interactive flag. Is the change really wanted there? Note Magnus explicitely commented about those in his original post. I noticed that but the output would be the same because there is no input file location to trigger. I thought the interactive flag was there just to provide more customized text. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] psql \set vs \copy - bug or expected behaviour?
Bruce Momjian br...@momjian.us writes: On Fri, Oct 21, 2011 at 05:31:41PM -0400, Robert Haas wrote: I'm not sure whether that's a bug per se, but I can see where a behavior change might be an improvement. I did some research on this and learned a little more about flex rules. Turns out we can allow variable substitution in psql whole-line commands, like \copy and \!, by sharing the variable expansion flex rules with the code that does argument processing. Well, it'd be nice to allow substitution there ... What we can't easily do is to allow quotes to prevent variable substitution in these whole-line commands because we can't process the quotes because that will remove them. ... but if there is then no way to prevent it, that's absolutely unacceptable. 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] psql \set vs \copy - bug or expected behaviour?
On 17/08/12 18:38, Tom Lane wrote:
Bruce Momjianbr...@momjian.us writes:
On Fri, Oct 21, 2011 at 05:31:41PM -0400, Robert Haas wrote:
I'm not sure whether that's a bug per se, but I can see where a
behavior change might be an improvement.
I did some research on this and learned a little more about flex rules.
Turns out we can allow variable substitution in psql whole-line
commands, like \copy and \!, by sharing the variable expansion flex
rules with the code that does argument processing.
Well, it'd be nice to allow substitution there ...
What we can't easily do is to allow quotes to prevent variable
substitution in these whole-line commands because we can't process the
quotes because that will remove them.
... but if there is then no way to prevent it, that's absolutely
unacceptable.
If I'm understanding this correctly, \copy parsing just passes the query
part unaltered as part of a COPY statement back into the top-level
parser. Likewise with the \!shell stuff (but presumably to execve).
To handle variable-substitution correctly for \copy we'd need to
duplicate the full parsing for COPY. For \! we'd need something which
understood shell-syntax (for the various shells out there). Ick.
Or you'd need a separate variable-bracketing {{:x}} syntax that could
work like reverse dollar-quoting. Also Ick.
As far as we know this has only inconvenienced one person (me) badly
enough to report a maybe-bug. Thanks for trying Bruce, but I fear this
is one itch that'll go unscratched.
Rest assured I'm not about to storm off and replace all my installations
with MySQL :-)
--
Richard Huxton
Archonet Ltd
--
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] psql \set vs \copy - bug or expected behaviour?
On Fri, Aug 17, 2012 at 06:55:14PM +0100, Richard Huxton wrote:
Well, it'd be nice to allow substitution there ...
What we can't easily do is to allow quotes to prevent variable
substitution in these whole-line commands because we can't process the
quotes because that will remove them.
... but if there is then no way to prevent it, that's absolutely
unacceptable.
If I'm understanding this correctly, \copy parsing just passes the
query part unaltered as part of a COPY statement back into the
top-level parser. Likewise with the \!shell stuff (but presumably to
execve).
To handle variable-substitution correctly for \copy we'd need to
duplicate the full parsing for COPY. For \! we'd need something
which understood shell-syntax (for the various shells out there).
Ick.
Or you'd need a separate variable-bracketing {{:x}} syntax that
could work like reverse dollar-quoting. Also Ick.
As far as we know this has only inconvenienced one person (me) badly
enough to report a maybe-bug. Thanks for trying Bruce, but I fear
this is one itch that'll go unscratched.
Rest assured I'm not about to storm off and replace all my
installations with MySQL :-)
Good analysis. Basically we can't hope to fully understand COPY or
shell quoting syntax well enough to properly replace only unquoted psql
variable references.
Therefore, unless I hear otherwise, I will just document the limitation
and withdraw the patch.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
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] psql \set vs \copy - bug or expected behaviour?
On Fri, Oct 21, 2011 at 05:31:41PM -0400, Robert Haas wrote:
On Fri, Oct 21, 2011 at 7:24 AM, Richard Huxton d...@archonet.com wrote:
It looks like \copy is just passing the text of the query unadjusted to
COPY. I get a syntax error on :x with the \copy below on both 9.0 and
9.1
=== test script ===
\set x '''HELLO'''
-- Works
\echo :x
-- Works
\o '/tmp/test1.txt'
COPY (SELECT :x) TO STDOUT;
-- Doesn't work
\copy (SELECT :x) TO '/tmp/test2.txt'
=== end script ===
I'm not sure whether that's a bug per se, but I can see where a
behavior change might be an improvement.
I did some research on this and learned a little more about flex rules.
Turns out we can allow variable substitution in psql whole-line
commands, like \copy and \!, by sharing the variable expansion flex
rules with the code that does argument processing.
What we can't easily do is to allow quotes to prevent variable
substitution in these whole-line commands because we can't process the
quotes because that will remove them.
Here are some examples; \copy and \! behave the same:
test= \set x abc
test= \echo :x
abc
test= \echo :x
-- :x
test= \! echo :x
abc
test= \! echo :x
-- abc
Notice the last line has expanded :x even though it is in quotes.
So, what do we want? The attached patch is pretty short.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/src/bin/psql/psqlscan.l b/src/bin/psql/psqlscan.l
new file mode 100644
index 1208c8f..3732dc5
*** a/src/bin/psql/psqlscan.l
--- b/src/bin/psql/psqlscan.l
*** other .
*** 934,949
}
! xslasharg{
/*
* Default processing of text in a slash command's argument.
*
* Note: unquoted_option_chars counts the number of characters at the
* end of the argument that were not subject to any form of quoting.
* psql_scan_slash_option needs this to strip trailing semicolons safely.
*/
! {space}|\\ {
/*
* Unquoted space is end of arg; do not eat. Likewise
* backslash is end of command or next command, do not eat
--- 934,956
}
!
/*
* Default processing of text in a slash command's argument.
+ * It shares token actions with xslasharg and xslashwholeline.
*
* Note: unquoted_option_chars counts the number of characters at the
* end of the argument that were not subject to any form of quoting.
* psql_scan_slash_option needs this to strip trailing semicolons safely.
*/
! xslashwholeline{space}+ {
! /* process entire line, but suppress leading whitespace */
! if (output_buf-len 0)
! ECHO;
! }
!
! xslasharg{space}|\\ {
/*
* Unquoted space is end of arg; do not eat. Likewise
* backslash is end of command or next command, do not eat
*** other .
*** 957,982
return LEXRES_OK;
}
! {quote} {
! *option_quote = '\'';
! unquoted_option_chars = 0;
! BEGIN(xslashquote);
! }
!
! `{
backtick_start_offset = output_buf-len;
*option_quote = '`';
unquoted_option_chars = 0;
BEGIN(xslashbackquote);
}
! {dquote} {
ECHO;
*option_quote = '';
unquoted_option_chars = 0;
BEGIN(xslashdquote);
}
:{variable_char}+ {
/* Possible psql variable substitution */
if (option_type == OT_NO_EVAL)
--- 964,1005
return LEXRES_OK;
}
! xslasharg` {
! /* Only in xslasharg, so backticks are potentially passed to the shell */
backtick_start_offset = output_buf-len;
*option_quote = '`';
unquoted_option_chars = 0;
BEGIN(xslashbackquote);
}
! xslasharg{quote} {
! *option_quote = '\'';
! unquoted_option_chars = 0;
! BEGIN(xslashquote);
! }
!
! xslasharg{dquote} {
ECHO;
*option_quote = '';
unquoted_option_chars = 0;
BEGIN(xslashdquote);
}
+ xslasharg{other} {
+ unquoted_option_chars++;
+ ECHO;
+ }
+
+ xslashwholeline{other} { ECHO; }
+
+ /*
+ * This code allows variable processing in slasharg and wholeline
+ * modes. wholeline does not allow quoting to prevent variable
+ * subtitution because quote detection would remove the quotes.
+ */
+
+ xslasharg,xslashwholeline{
+
:{variable_char}+ {
/* Possible psql variable substitution */
if (option_type == OT_NO_EVAL)
*** other .
*** 1044,1054
ECHO;
}
- {other} {
- unquoted_option_chars++;
- ECHO;
- }
-
}
xslashquote{
--- 1067,1072
*** other .
*** 1115,1133
}
- xslashwholeline{
- /* copy everything until end of input line */
- /* but suppress leading whitespace */
-
- {space}+ {
- if (output_buf-len 0)
-
Re: [HACKERS] psql tab completion for GRANT role
On tor, 2012-06-14 at 13:38 -0400, Robert Haas wrote: On Sun, Jan 8, 2012 at 3:48 PM, Peter Eisentraut pete...@gmx.net wrote: psql tab completion currently only supports the form GRANT privilege ON something TO someone (and the analogous REVOKE), but not the form GRANT role TO someone. Here is a patch that attempts to implement the latter. This seems to have fallen through the cracks. No, it was committed in January. -- 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] psql tab completion for GRANT role
On Tue, Jun 19, 2012 at 3:16 AM, Peter Eisentraut pete...@gmx.net wrote: On tor, 2012-06-14 at 13:38 -0400, Robert Haas wrote: On Sun, Jan 8, 2012 at 3:48 PM, Peter Eisentraut pete...@gmx.net wrote: psql tab completion currently only supports the form GRANT privilege ON something TO someone (and the analogous REVOKE), but not the form GRANT role TO someone. Here is a patch that attempts to implement the latter. This seems to have fallen through the cracks. No, it was committed in January. Oops, I missed that. Sorry for the noise. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] psql tab completion for GRANT role
On Sun, Jan 8, 2012 at 3:48 PM, Peter Eisentraut pete...@gmx.net wrote: psql tab completion currently only supports the form GRANT privilege ON something TO someone (and the analogous REVOKE), but not the form GRANT role TO someone. Here is a patch that attempts to implement the latter. This seems to have fallen through the cracks. It doesn't apply any more, but one general comment is that it seems undesirable to repeatedly recapitulate the list of all privileges that exist in the system. That's a lot of places that someone will have to find and fix when new privileges are added. But +1 on the general idea. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] psql bug
Teodor Sigaev teo...@sigaev.ru writes: Seems system() call cleanups sigaction state on FreeBSD. The root of problem is a threading library. In FreeBSD there are two versions of sigaction() (system() and others) depending on thread enabled. libpq library is compiled by default with -pthread switch but psql is linked without that. This mixed linkage is a reason why system() call for external program loses signal handler. Next, configure script correctly sets PTHREAD_* variables but PTHREAD_LIBS is not used for psql linking. What is the best way to fix that? I suggest to add PTHREAD_LIBS to linking psql at least. Although, suppose, it could be a reason for other cryptic bugs. We could probably fix this by adding something like this to Makefile.freebsd: libpq += $(PTHREAD_LIBS) However, the more I think about this, the more I think it is a FreeBSD bug and the right solution is to complain loudly to the maintainers of that platform. The above hack might fix things for programs we ship as part of Postgres, but what of other programs using libpq? It cannot be rational to expect that if libpq is linked to libpthread, then every program that links to libpq must also be explicitly linked to libpthread. FreeBSD's linker is broken and they need to fix it, or else they need to fix libpthread to be less invasive. (Another reason for thinking this is that surely we'd have heard about it before if this behavior were of long standing. My money is on a fairly recently introduced bug.) 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] psql bug
Seems system() call cleanups sigaction state on FreeBSD. The root of problem is a threading library. In FreeBSD there are two versions of sigaction() (system() and others) depending on thread enabled. libpq library is compiled by default with -pthread switch but psql is linked without that. This mixed linkage is a reason why system() call for external program loses signal handler. Next, configure script correctly sets PTHREAD_* variables but PTHREAD_LIBS is not used for psql linking. What is the best way to fix that? I suggest to add PTHREAD_LIBS to linking psql at least. Although, suppose, it could be a reason for other cryptic bugs. I didn't test this solution on other OSes, but, suppose, it will work. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ -- 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] psql bug
will investigate that Tom Lane wrote: Teodor Sigaevteo...@sigaev.ru writes: After editing query with external editor psql exits on Ctrl-C: FWIW, I failed to reproduce that on any of my machines. Maybe your editor is leaving the tty in a funny state? regards, tom lane -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ -- 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] psql bug
FWIW, I failed to reproduce that on any of my machines. Maybe
your editor is leaving the tty in a funny state?
Seems system() call cleanups sigaction state on FreeBSD. I've modify
void
setup_cancel_handler(void)
{
fprintf(stderr, %p - %p\n, pqsignal(SIGINT, handle_sigint),
handle_sigint);
}
and add it around system() call. Next:
% export EDITOR=echo
% psql postgres
0x0 - 0x409620
SET
Timing is on.
psql (9.2beta1)
Type help for help.
postgres=# \e
0x409620 - 0x409620
/tmp/psql.edit.7997.sql
0x0 - 0x409620
postgres=#
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
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] psql bug
Teodor Sigaev teo...@sigaev.ru writes: After editing query with external editor psql exits on Ctrl-C: FWIW, I failed to reproduce that on any of my machines. Maybe your editor is leaving the tty in a funny state? 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] psql: server version check for \dO
On Thu, May 10, 2012 at 7:09 AM, Josh Kupershmidt schmi...@gmail.com wrote: Hi all, I think psql's \dO command is missing the server version check which similar commands such as \dx use. Right now \dO errors out with: test=# \dO ERROR: relation pg_catalog.pg_collation does not exist when talking to servers older than 9.1, which don't have pg_collation. Simple patch for listCollations() attached. Indeed. Thanks, applied and backpatched to 9.1. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] psql omits row count under \x auto
On Fri, Apr 27, 2012 at 3:05 PM, Noah Misch n...@leadboat.com wrote: On Thu, Apr 26, 2012 at 09:25:25PM +0300, Peter Eisentraut wrote: On m??n, 2012-04-23 at 12:30 -0400, Noah Misch wrote: I've been enjoying \x auto in .psqlrc, but I noticed the row count footer missing when it chooses ordinary output: Looks like the logic in printQuery() needs further treatment. Hmm, this looks a bit tricky, because at the time we add the footer we don't yet know which output format will be used. I don't have a good idea how to fix that at the moment. I fiddled with this and settled on moving the default_footer boolean setting and the interpretation thereof down from the printQuery() level to the printTable() level. That permits delaying the decision until we determine whether the final output format is indeed vertical. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] psql omits row count under \x auto
On Thu, Apr 26, 2012 at 09:25:25PM +0300, Peter Eisentraut wrote:
On m??n, 2012-04-23 at 12:30 -0400, Noah Misch wrote:
I've been enjoying \x auto in .psqlrc, but I noticed the row count footer
missing when it chooses ordinary output:
Looks like the logic in printQuery() needs further treatment.
Hmm, this looks a bit tricky, because at the time we add the footer we
don't yet know which output format will be used. I don't have a good
idea how to fix that at the moment.
I fiddled with this and settled on moving the default_footer boolean setting
and the interpretation thereof down from the printQuery() level to the
printTable() level. That permits delaying the decision until we determine
whether the final output format is indeed vertical.
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
***
*** 2407,2418 do_pset(const char *param, const char *value, printQueryOpt
*popt, bool quiet)
else if (strcmp(param, footer) == 0)
{
if (value)
! popt-default_footer = ParseVariableBool(value);
else
! popt-default_footer = !popt-default_footer;
if (!quiet)
{
! if (popt-default_footer)
puts(_(Default footer is on.));
else
puts(_(Default footer is off.));
--- 2407,2418
else if (strcmp(param, footer) == 0)
{
if (value)
! popt-topt.default_footer = ParseVariableBool(value);
else
! popt-topt.default_footer = !popt-topt.default_footer;
if (!quiet)
{
! if (popt-topt.default_footer)
puts(_(Default footer is on.));
else
puts(_(Default footer is off.));
*** a/src/bin/psql/describe.c
--- b/src/bin/psql/describe.c
***
*** 1130,1135 describeOneTableDetails(const char *schemaname,
--- 1130,1136
retval = false;
+ myopt.default_footer = false;
/* This output looks confusing in expanded mode. */
myopt.expanded = false;
***
*** 2363,2368 describeRoles(const char *pattern, bool verbose)
--- 2364,2371
const char align = 'l';
char **attr;
+ myopt.default_footer = false;
+
initPQExpBuffer(buf);
if (pset.sversion = 80100)
***
*** 3362,3368 describeOneTSParser(const char *oid, const char *nspname,
const char *prsname)
sprintf(title, _(Text search parser \%s\), prsname);
myopt.title = title;
myopt.footers = NULL;
! myopt.default_footer = false;
myopt.translate_header = true;
myopt.translate_columns = translate_columns;
--- 3365,3371
sprintf(title, _(Text search parser \%s\), prsname);
myopt.title = title;
myopt.footers = NULL;
! myopt.topt.default_footer = false;
myopt.translate_header = true;
myopt.translate_columns = translate_columns;
***
*** 3393,3399 describeOneTSParser(const char *oid, const char *nspname,
const char *prsname)
sprintf(title, _(Token types for parser \%s\), prsname);
myopt.title = title;
myopt.footers = NULL;
! myopt.default_footer = true;
myopt.translate_header = true;
myopt.translate_columns = NULL;
--- 3396,3402
sprintf(title, _(Token types for parser \%s\), prsname);
myopt.title = title;
myopt.footers = NULL;
! myopt.topt.default_footer = true;
myopt.translate_header = true;
myopt.translate_columns = NULL;
***
*** 3725,3731 describeOneTSConfig(const char *oid, const char *nspname,
const char *cfgname,
myopt.nullPrint = NULL;
myopt.title = title.data;
myopt.footers = NULL;
! myopt.default_footer = false;
myopt.translate_header = true;
printQuery(res, myopt, pset.queryFout, pset.logfile);
--- 3728,3734
myopt.nullPrint = NULL;
myopt.title = title.data;
myopt.footers = NULL;
! myopt.topt.default_footer = false;
myopt.translate_header = true;
printQuery(res, myopt, pset.queryFout, pset.logfile);
*** a/src/bin/psql/print.c
--- b/src/bin/psql/print.c
***
*** 44,49 static char *decimal_point;
--- 44,52
static char *grouping;
static char *thousands_sep;
+ static char default_footer[100];
+ static printTableFooter default_footer_cell = { default_footer, NULL };
+
/* Line style control structures */
const printTextFormat pg_asciiformat =
{
***
*** 278,283 print_separator(struct separator sep, FILE *fout)
--- 281,314
}
+ /*
+ * Return
Re: [HACKERS] psql omits row count under \x auto
On mån, 2012-04-23 at 12:30 -0400, Noah Misch wrote: I've been enjoying \x auto in .psqlrc, but I noticed the row count footer missing when it chooses ordinary output: Looks like the logic in printQuery() needs further treatment. Hmm, this looks a bit tricky, because at the time we add the footer we don't yet know which output format will be used. I don't have a good idea how to fix that at the moment. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
