Re: [HACKERS] [patch] A \pivot command for psql

David Fetter wrote: That said, a thing in psql that could slice serialized output into columns would be handy as a broad, general part of reporting in psql To avoid any confusion with server-side PIVOT, I suggest that the currently proposed command in psql should have a different name

Re: [HACKERS] [patch] psql tab completion for grant execute

Robert Haas wrote: A trivial patch is attached. It adds the condition that if EXECUTE is preceded by GRANT itself preceded by nothing, then that completion with PROCEDURE is skipped. Thanks, I committed this. I don't think we usually back-patch tab completion fixes, but I

[HACKERS] [patch] psql tab completion for grant execute

Hi, When tab-completing after GRANT EXECUTE, currently psql injects PROCEDURE, rather than the expected ON. The code for completing with ON is there, but it's not reached due to falling earlier into another branch, one that handles CREATE TRIGGER. A trivial patch is attached. It adds the

Re: [HACKERS] [patch] A \pivot command for psql

David Fetter wrote: That depends on what you mean by dynamic columns. The approach taken in the tablefunc extension is to use functions which return SETOF RECORD, which in turn need to be cast at runtime. For me, PIVOT with dynamic columns would be a pivot query whose output columns

Re: [HACKERS] [patch] A \pivot command for psql

David Fetter wrote: Second, if we put this feature as-is in psql, we're stuck supporting it in psql until the end of time, even if (when, I believe) we have a fuller and likely not perfectly compatible feature on the back-end. To me, doing \pivot in psql vs PIVOT in the backend is a

[HACKERS] [patch] A \pivot command for psql

Hi, I want to suggest a client-side \pivot command in psql, implemented in the attached patch. \pivot takes the current query in the buffer, execute it and display it pivoted by interpreting the result as: column1 = row in pivoted output column2 = column in pivoted output column3 = value at

Re: [HACKERS] [patch] A \pivot command for psql

Tom Lane wrote: Is there a way to implement pivoting as a set-returning function? Not with the same ease of use. We have crosstab functions in contrib/tablefunc already, but the killer problem with PIVOT is that truly dynamic columns are never reachable directly. If we could do this:

Re: [HACKERS] [patch] A \pivot command for psql

Tom Lane wrote: I'm not sure how pushing it out to psql makes that better. There is no way to do further processing on something that psql has printed, so you've punted on solving that issue just as much if not more. It's the same spirit as \x : the only thing it achieves is better

Re: [HACKERS] [patch] A \pivot command for psql

David Fetter wrote: I'm working up a proposal to add (UN)PIVOT support to the back-end. I was under the impression that a server-side PIVOT *with dynamic columns* was just unworkable as an SQL query, because it couldn't be prepared if it existed. I am wrong on that? I feel like you

Re: [HACKERS] psql: add \pset true/false

Marko Tiikkaja wrote: > Since the default t/f output for booleans is not very user friendly, > attached is a patch which enables you to do for example the following: Personally I think it would be worth having, but how about booleans inside ROW() or composite types ? test=> \pset true

Re: [HACKERS] psql: add \pset true/false

Matthijs van der Vleuten wrote: > -1 for changing boolout(). It will break anything that receives > boolean values from the server. Not if the default output is still 't' or 'f' like now. Nobody seems to suggest a gratuitous compatibility break. > How a client is going to display

Re: [HACKERS] [patch] Proposal for \rotate in psql

Pavel Stehule wrote: > I am looking on this last patch. I talked about the name of this command > with more people, and the name "rotate" is unhappy. The correct name for > this visualization technique is "crosstab" (see google "crosstab"). The > conflict with our extension is unhappy,

Re: [HACKERS] [patch] Proposal for \rotate in psql

Joe Conway wrote: > but if you don't want to conflict with the name > crosstab, perhaps "pivot" would be better? Initially I had chosen \pivot without much thought about it, but the objection was raised that a PIVOT/UNPIVOT SQL feature would likely exist in core in a next release

Re: [HACKERS] [patch] Proposal for \rotate in psql

I wrote: > What I like in that representation is that it looks good enough > to be pasted directly into a document in a word processor. And ironically, the nice unicode borders came out all garbled in the mail, thanks to a glitch in my setup that mis-reformatted them before sending. Sorry

Re: [HACKERS] [patch] Proposal for \rotate in psql

Pavel Stehule wrote: > the name "rotate" is not correct - maybe "\cross" ? I'm not dead set on \rotate and suggested other names previously in [1], but none of them seems decisively superior. The rationale behind rotate is that, it's a synonym of pivot as a verb, and it's not already

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

Victor Wagner wrote: > It would just take a bit more time for client and a bit more load for > server - to make sure that this connection is read-write by > issuing > >show transaction_read_only > > statement before considering connection useful. If the purpose of the feature is

Re: [HACKERS] [patch] Proposal for \rotate in psql

Pavel Stehule wrote: > rotate ~ sounds like transpose matrix, what is not true in this case. The various definitions that I can see, such as http://dictionary.reference.com/browse/rotate make no mention of matrices. It applies to anything that moves around a pivot or axis. OTOH, the

Re: [HACKERS] [patch] Proposal for \rotate in psql

Hi, This is the 2nd iteration of this patch, for comments and review. Changes: - the arguments can be column names (rather than only numbers). - the horizontal headers are sorted server-side according to their original type. DESC order is possible by prefixing the column arg with a minus

Re: [HACKERS] [patch] Proposal for \rotate in psql

Pavel Stehule wrote: > 2. Data column are not well aligned - numbers are aligned as text Thanks for spotting that, it's fixed in the attached new iteration of the patch. > 3. When data are multiattribute - then merging together with space separator > is not practical > > * important

Re: [HACKERS] [patch] Proposal for \rotate in psql

Pavel Stehule wrote: > my comments: > > 1. I don't understand why you are use two methods for sorting columns > (qsort, and query with ORDER BY) qsort (with strcmp as the comparator) is only used to determine the set of distinct values for the vertical and horizontal headers. In fact

Re: [HACKERS] [patch] Proposal for \rotate in psql

Pavel Stehule wrote: > in the help inside your last patch, you are using "crosstab". Cannto be > crosstab the name for this feature? If it wasn't taken already by contrib/tablefunc, that would be a first choice. But now, when searching for crosstab+postgresql, pages of results come out

Re: [HACKERS] [patch] Proposal for \rotate in psql

Pavel Stehule wrote: > > So not using \crosstab is deliberate; it's to prevent confusion with > > the server-side function. > > I don't afraid about this - crosstab is a function in extension. Psql > backslash commands living in different worlds. Sure, but the confusion would be

[HACKERS] [patch] Proposal for \rotate in psql

Hi, This is a reboot of my previous proposal for pivoting results in psql, with a new patch that generalizes the idea further through a command now named \rotate, and some examples. So the concept is: having an existing query in the query buffer, the user can specify two column numbers C1 and

[HACKERS] Should psql exit when the log file can't be written into?

Hi, Following last week's commit 344cdff : Author: Tom Lane Date: Thu Dec 3 14:28:58 2015 -0500 Clean up some psql issues around handling of the query output file. Formerly, if "psql -o foo" failed to open the output file "foo", it would print an error

Re: [HACKERS] psql: add \pset true/false

Michael Paquier wrote: > So, looking at this thread, here is the current status: > - Tom Lane: -1 > - Michael Paquier: -1 > - Peter Geoghegan: +1? > - Peter Eisentraut: +1 > - the author: surely +1. > Any other opinions? Feel free to correct this list if needed, and then > let's try to

Re: [HACKERS] psql: add \pset true/false

Jim Nasby wrote: > I was more thinking it would be nice to be able to temporarily > over-ride/wrap what an output function is doing. AFAIK that would allow > this to work everywhere (row(), copy, etc). I don't know of any remotely > practical way to do that, though. Yes. Something

Re: [HACKERS] [patch] Proposal for \rotate in psql

Pavel Stehule wrote: > postgres=# \crosstabview 4 +month label > > Maybe using optional int order column instead label is better - then you can > do sort on client side > > so the syntax can be "\crosstabview VCol [+/-]HCol [[+-]HOrderCol] In the meantime I've followed a different

Re: [HACKERS] [patch] Proposal for \rotate in psql

Pavel Stehule wrote: > here is patch - supported syntax: \crosstabview VCol [+/-]HCol [HOrderCol] > > Order column should to contains any numeric value. Values are sorted on > client side If I understand correctly, I see a problem with HOrderCol. If the vertical header consists of,

Re: [HACKERS] [patch] Proposal for \rotate in psql

Pavel Stehule wrote: > The symbol 'X' in two column mode should be centred - now it is aligned to > left, what is not nice Currently print.c does not support centered alignment, only left and right. Should we add it, it would have to work for all output formats (except obviously for

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Hi, Here's an updated patch that replaces sorted arrays by AVL binary trees when gathering distinct values for the columns involved in the pivot. The change is essential for large resultsets. For instance, it allows to process a query like this (10 million rows x 10 columns): select

Re: [HACKERS] [patch] Proposal for \rotate in psql

Pavel Stehule wrote: > [ \rotate being a wrong name ] Here's an updated patch. First it renames the command to \crosstabview, which hopefully may be more consensual, at least it's semantically much closer to crosstab . > The important question is sorting output. The vertical header is

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

Shulgin, Oleksandr wrote: > Added to the Open commitfest: https://commitfest.postgresql.org/9/475/ Here's a review. Note that the patch tested and submitted is not the initial one in the thread, so it doesn't exactly match $subject now. What's tested here is a client-side approach,

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Alvaro Herrera wrote: > So please can we have that wiki page so that the syntax can be hammered > out a bit more. Sure, I'm on it. > I'm closing this as returned-with-feedback for now. Well, the feedback it got during months was incorporated into the patch in the form of significant

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Alvaro Herrera wrote: > Also, what about the business of putting "x" if there's no third column? > Three months from now some Czech psql hacker will say "we should use > Unicode chars for this" and we will be forever stuck with \pset > unicode_crosstab_marker to change the character to a

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Alvaro Herrera wrote: > While I understand that you may think that "silence is consent", > what I am afraid of is that some committer will look at this two > months from now and say "I hate this Hcol+ stuff, -1 from me" and > send the patch back for syntax rework. IMO it's better to have

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Teodor Sigaev wrote: > Interesting feature, but it's not very obvious how to use it. I'd like to > see some example(s) in documentation. I'm thinking of making a wiki page, because examples pretty much require showing resultsets, and I'm not sure this would fly with our current psql

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Dean Rasheed wrote: > I don't think we should allow sorting colV values client-side, > overriding a server-side ORDER BY clause in the query. I shared that opinion until (IIRC) the v8 or v9 of the patch. Most of the evolution of this patch has been to go from no client-side sorting

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Dean Rasheed wrote: > Note that I might also want to pass additional sort options, such as > "ORDER BY name NULLS LAST", which the existing syntax doesn't allow. > In the new syntax, such sort options could be trivially supported in > both the server- and client-side sorts: Note that

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

Shulgin, Oleksandr wrote: > Most importantly, I'd like to learn of better options than storing the > whole last_result in psql's pset structure. I guess that you could, each time a query fails, gather silently the result of \errverbose, store it in a buffer, discard the PGresult, and in

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Tom Lane wrote: > I do not think we want any client-side sorting in this feature at all, > because the minute you have any such thing, you are going to have an > absolutely never-ending stream of demands for more sorting features: > multi column, numeric vs text, ASC vs DESC,

Re: [HACKERS] Why format() adds double quote?

Tatsuo Ishii wrote: > 2) What does the SQL standard say? Do they say that non ASCII white > spaces should be treated as ASCII white spaces? I've used white space in the example, but I'm concerned about punctuation too. unicode.org has this helpful paper:

Re: [HACKERS] Why format() adds double quote?

Tatsuo Ishii wrote: > What is the "visual hint"? If you are talking about psql's output, it > never adds "visual hint" (double quotations). > > If you are talking about the string handling in a program, what kind > of program cares about "visiual"? Sure. The scenario I'm thinking

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Pavel Stehule wrote: > 1. maybe we can decrease name to shorter "crossview" ?? I am happy with > crosstabview too, just crossview is correct too, and shorter I'm in favor of keeping crosstabview. It's more explicit, only 3 characters longer and we have tab completion anyway. > 2.

Re: [HACKERS] 2016-01 Commitfest

Alvaro Herrera wrote: > https://commitfest.postgresql.org/8/372/ > \crosstabview (previously: \rotate) in psql for crosstab-style display About this one, the code is no longer moving, the latest addition was regression tests a couple days ago. I think it should be moved to the next

Re: [HACKERS] psql metaqueries with \gexec

Corey Huinker wrote: > ...and query text visibility, and result visibility, and error handling, > etc. In this case, we're leveraging the psql environment we'd already set > up, and if there's an error, \set ECHO queries shows us the errant SQL as > if we typed it ourselves.. BTW, about

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Hi, Here's an updated patch improving on how the horizontal and vertical headers can be sorted. The discussion upthread went into how it was desirable to have independant sorts for these headers, possibly driven by another column, in addition to the query's ORDER BY. Thus the options now

Re: [HACKERS] Why format() adds double quote?

Tatsuo Ishii wrote: > IMO, it's a bug or at least an inconsistency Personally I don't see this change being good for everything. Let's play devil's advocate: create table abc(U&"foo\2003" int); U+2003 is 'EM SPACE', in Unicode's General Punctuation block. With the current version,

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Alvaro Herrera wrote: > So please can we have that wiki page so that the syntax can be hammered > out a bit more. I've added a wiki page with explanation and examples here: https://wiki.postgresql.org/wiki/Crosstabview Best regards, -- Daniel Vérité PostgreSQL-powered mailer:

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Dean Rasheed wrote: > My biggest problem is with the sorting, for all the reasons discussed > above. There is absolutely no reason for \crosstabview to be > re-sorting rows -- they should just be left in the original query > result order We want the option to sort the vertical the header

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Jim Nasby wrote: > > ORDER BY name > > \crosstabview cols = (select to_char(d, 'Mon') from > > generate_series('2000-01-01'::date, '2000-12-01', '1 month') d) > > My concern with that is that often you don't know what the columns will > be, because you don't know what exact data the

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Daniel Verite wrote: > > > ORDER BY name > > > \crosstabview cols = (select to_char(d, 'Mon') from > > > generate_series('2000-01-01'::date, '2000-12-01', '1 month') d) > > > > My concern with that is that often you don't know what the columns wi

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Peter Eisentraut wrote: > On 2/9/16 11:21 AM, Daniel Verite wrote: > > Note that NULL values in the column that pivots are discarded > > by \crosstabview, because NULL as the name of a column does not > > make sense. > > Why not? > > All you're d

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Dean Rasheed wrote: > If I want to sort the rows coming out of a query, my first thought > is always going to be to add/adjust the query's ORDER BY clause, not > use some weird +/- psql syntax. About the vertical sort, I agree on all your points. It's best to rely on ORDER BY for all the

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

I wrote: > If splitting the table into 3 fields, each smaller than 512MB: > > postgres=# create table big2 as select > substring(binarycol from 1 for 300*1024*1024) as b1, > substring(binarycol from 1+300*1024*1024 for 300*1024*1024) as b2 , > substring(binarycol from 1+600*1024*1024

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Jim Nasby wrote: > Ultimately I'd really like some way to remove/reduce the restriction of > result set definitions needing to be determined at plan time. That would > open the door for server-side crosstab/pivot as well a a host of other > things (such as dynamically turning a

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Robert Haas wrote: > But worse than either of those things, there is no real > agreement on what the overall design of this feature > should be. The part in the design that raised concerns upthread is essentially how headers sorting is exposed to the user and implemented. As suggested

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Alvaro Herrera wrote: Thanks for looking into that patch! > regression=# select * from pg_class \crosstabview relnatts > \crosstabview: missing second argument > regression-# Fixed. This was modelled after the behavior of: select 1 \badcommand but I've changed to mimic what happens

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Alvaro Herrera wrote: > I messed with that code some more, as it looked unnecessarily > complicated; please see attached and verify that it still behaves > sanely. This needs those regression tests you promised. I tested a few > cases and it seems good to me. I've fixed a couple things

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Alvaro Herrera wrote: > I wonder if the business of appending values of multiple columns > separated with spaces is doing us any good. Why not require that > there's a single column in the cell? If the user wants to put things > together, they can use format() or just || the fields

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Alvaro Herrera wrote: > I pushed it. That's awesome, thanks! Also thanks to Pavel who reviewed and helped continuously when iterating on this feature, and all others who participed in this thread. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Daniel Verite wrote: > # \copy bigtext2 from '/var/tmp/bigtext.sql' > ERROR: 54000: out of memory > DETAIL: Cannot enlarge string buffer containing 1073741808 bytes by 8191 > more bytes. > CONTEXT: COPY bigtext2, line 1 > LOCATION: enlargeStringInfo, stringinfo

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Alvaro Herrera wrote: > > tuple = (HeapTuple) palloc0(HEAPTUPLESIZE + len); > > > > which fails because (HEAPTUPLESIZE + len) is again considered > > an invalid size, the size being 1468006476 in my test. > > Um, it seems reasonable to make this one be a huge-zero-alloc: > >

Re: [HACKERS] raw output from copy

Corey Huinker wrote: > So, for me, RAW is the right solution, or at least *a* right solution. Questions on how to extract from a bytea column come up on a regular basis, as in [1] [2] [3], or [4] a few days ago, and so far the answers are to encode the contents in text and decode them in

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Tomas Vondra wrote: > My guess is this is a problem at the protocol level - the 'd' message is > CopyData, and all the messages use int32 to define length. So if there's > a 2GB row, it's likely to overflow. Yes. Besides, the full message includes a negative length: > postgres=# \copy

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Tom Lane wrote: > BTW, is anyone checking the other side of this, ie "COPY IN" with equally > wide rows? There doesn't seem to be a lot of value in supporting dump > if you can't reload ... Indeed, the lines bigger than 1GB can't be reloaded :( My test: with a stock 9.5.1 plus Alvaro's

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Alvaro Herrera wrote: > If others can try this patch to ensure it enables pg_dump to work on > their databases, it would be great. It doesn't seem to help if one field exceeds 1Gb, for instance when inflated by a bin->hex translation. postgres=# create table big as select

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

I wrote: > postgres=# \copy big2 to /dev/null > lost synchronization with server: got message type "d", length -1568669676 > > The backend aborts with the following backtrace: > > Program terminated with signal 6, Aborted. > #0 0x7f82ee68e165 in raise () from

Re: [HACKERS] raw output from copy

Andrew Dunstan wrote: > If someone can make a good case that this is going to be of > general use I'll happily go along, but I haven't seen one so far. About COPY FROM with a raw format, for instance just yesterday there was this user question on stackoverflow:

Re: [HACKERS] raw output from copy

Andrew Dunstan wrote: > Inserting the whole contents of a text file unchanged is insanely easy > in psql. > > \set file `cat /path/to/file` > insert into mytable(contents) values(:'file'); That's assuming psql but the asker of that question never mentioned using psql. The

Re: [HACKERS] raw output from copy

Tom Lane wrote: > >> Code that uses PQexecParams() binary "resultFormat", or the > >> binary format of copy doesn't have that problem, but most > >> client-side drivers don't do that. > > > And maybe they just can't realistically, because getting result > > format in binary is exposed

Re: [HACKERS] \crosstabview fixes

Christoph Berg wrote: > If there's no way out, what about changing it the other way, i.e. > breaking the case where the column is named by a number? That seems > much less of a problem in practice. I don't think it would be acceptable. But there's still the option of keeping the

Re: [HACKERS] \crosstabview fixes

Tom Lane wrote: > > That would be OK with me; it's certainly less of a hack than what's > > there now. (I went back and forth about how much effort to put into > > dealing with the colon syntax; I think the version I have in my patch > > would be all right, but it's not perfect.) > >

Re: [HACKERS] \crosstabview fixes

Christoph Berg wrote: > > I don't quite see how to work around that, short of simply > > removing the possibility of addressing columns by their > > numbers. [...] > That would be bad news, given that \crosstabview is meant for > interactive use where these number shortcuts are much more

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas wrote: > Of course, we could make this value 1-based rather than 0-based, as > Peter Geoghegan suggested a while back. But as I think I said at the > time, I think that's more misleading than helpful. The leader > participates in the parallel plan, but typically does far

Re: [HACKERS] \crosstabview fixes

Tom Lane wrote: > Pushed, thanks. > BTW, I see we've been spelling your name with an insufficient number > of accents in the commit logs and release notes. Can't do much about > the logs, but will fix the release notes. I use myself the nonaccented version of my name in "From" headers,

Re: [HACKERS] \crosstabview fixes

Tom Lane wrote: > > "Daniel Verite" <dan...@manitou-mail.org> writes: > >> To avoid the confusion between "2:4" and "2":"4" or 2:4, > >> and the ambiguity with a possibly existing "2:4" column, > >>

Re: [HACKERS] \crosstabview fixes

Tom Lane wrote: > I wrote: > > My feeling is that what we should do is undo the change to use OT_SQLID, > > and in indexOfColumn() perform a downcasing/dequoting conversion that > > duplicates what OT_SQLID does in psqlscanslash.l. > > Here's an updated patch that does it that way, and

Re: [HACKERS] \crosstabview fixes

Tom Lane wrote: > I noticed that the \crosstabview documentation asserts that column name > arguments are handled per standard SQL semantics. In point of fact, > though, the patch expends a couple hundred lines to implement what is > NOT standard SQL semantics: matching unquoted names

Re: [HACKERS] [patch] \crosstabview documentation

David G. Johnston wrote: > > ​So I guess: > > "​ > crosstabview with only 2 output columns > ​ "​ > > ​https://wiki.postgresql.org/wiki/Crosstabview > ​(last section on that page) > > ​never got implemented It was implemented but eventually removed. I will update shortly this wiki

Re: [HACKERS] sslmode=require fallback

Magnus Hagander wrote: > > I don't understand why you want to change the default. Is it for > > performance? Has it been measured? > > > > > Yes. I've run into it multiple times, but I haven't specifically measured > it. But I've had more than one situation where turning it off has >

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Peter Eisentraut wrote: > You really have (at least) three options here: > > 1. Rename nothing > 2. Rename directory only > 3. Rename everything I vote for 1) as I believe the renaming will create more confusion than it's worth, not even considering the renaming of functions and views.

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Corey Huinker wrote: > I meant in the specific psql-context, does it do anything other > than (attempt to) terminate sent-but-not-received SQL queries? It cancels the current edit in the query buffer, including the case when it spans multiple lines. If we add the functionality that

Re: [HACKERS] Improvements in psql hooks for variables

Tom Lane wrote: > Moreover, the committed patch is inconsistent in that it forbids > only one of the above. Why is it okay to treat unset as "off", > but not okay to treat the default empty-string value as "on"? Treating unset (NULL in the value) as "off" comes from the fact that

Re: [HACKERS] One-shot expanded output in psql using \G

Stephen Frost wrote: > That's not how '\dx' works, as I pointed out, so I don't see having the > second character being 'x' to imply "\x mode" makes sense. \gx means "like \g but output with expanded display" It turns out that it's semantically close to "\g with \x" so I refered to it

Re: [HACKERS] Improvements in psql hooks for variables

I wrote: > This would allow the hook to distinguish between initialization and > unsetting, which in turn will allow it to deny the \unset in the > cases when it doesn't make any sense conceptually (like AUTOCOMMIT). I notice that in the commited patch, you added the ability for

Re: [HACKERS] Improvements in psql hooks for variables

Tom Lane wrote: > I updated the documentation as well. I think this is committable if > there are not objections. That works for me. I tested and read it and did not find anything unexpected or worth objecting. "\unset var" acting as "\set var off" makes sense considering that its

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Corey Huinker wrote: [about Ctrl-C] > That does seem to be the consensus desired behavior. I'm just not sure > where to handle that. The var "cancel_pressed" shows up in a lot of places. > Advice? Probably you don't need to care about cancel_pressed, and the /if stack could be unwound

Re: [HACKERS] Improvements in psql hooks for variables

Tom Lane wrote: > I took a quick look through this. It seems to be going in generally > the right direction, but here's a couple of thoughts: Here's an update with these changes: per Tom's suggestions upthread: - change ParseVariableBool() signature to return validity as bool. -

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Corey Huinker wrote: > > > > 1: unrecognized value "whatever" for "\if"; assuming "on" > > > > I do not think that the script should continue with such an assumption. > > > > I agree, and this means we can't use ParseVariableBool() as-is The patch at

Re: [HACKERS] Improvements in psql hooks for variables

I just wrote: > - add enum-style suggestions on invalid input for \pset x, \pset pager, > and \set of ECHO, ECHO_HIDDEN, ON_ERROR_ROLLBACK, COMP_KEYWORD_CASE, > HISTCONTROL, VERBOSITY, SHOW_CONTEXT, \x, \pager There's no such thing as \pager, I meant to write: \pset x, \pset pager, and

Re: [HACKERS] Improvements in psql hooks for variables

Tom Lane wrote: > However, it only really works if psql never overwrites the values > after startup, whereas I believe all of these are overwritten by > a \c command. Yes, there are reset to reflect the properties of the new connection. > So maybe it's more user-friendly to make these

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Corey Huinker wrote: > Revised patch A comment about control flow and variables: in branches that are not taken, variables are expanded nonetheless, in a way that can be surprising. Case in point: \set var 'ab''cd' -- select :var; \if false select :var ; \else select 1; \endif

Re: [HACKERS] One-shot expanded output in psql using \G

Christoph Berg wrote: > But do we really want to choose > something different just because MySQL is using it? That's not what I meant. If mysql wasn't using \G I'd still suggest the name \gx because: - it means the functionality of \g combined with \x so semantically it makes sense. -

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Corey Huinker wrote: > > \if ERROR > > \echo X > > \else > > \echo Y > > \endif > > > > having both X & Y printed and error reported on else and endif. I think > > that an expression error should just put the stuff in ignore state. > > > > Not just false, but ignore the

Re: [HACKERS] Improvements in psql hooks for variables

Tom Lane wrote: > Also, if you want to argue that allowing it to change intra- > transaction is too confusing, why would we only forbid this direction > of change and not both directions? The thread "Surprising behaviour of \set AUTOCOMMIT ON" at:

Re: [HACKERS] Improvements in psql hooks for variables

Tom Lane wrote: > Evidently, this test script is relying on the preceding behavior that > setting a bool variable to an empty string was equivalent to setting > it to "true". If it's just that script I would be okay with saying > "well, it's a bug in that script" ... but I'm a bit

Re: [HACKERS] One-shot expanded output in psql using \G

Christoph Berg wrote: > A workaround is to submit queries using "\x\g\x", but that's ugly, > clutters the output with toggle messages, and will forget that "\x > auto" was set. > > Mysql's CLI client is using \G for this purpose, and adding the very > same functionality to psql fits

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

Tom Lane wrote: > Ah, I see why *that* wants to know about it ... I think. I suppose you're > arguing that variable expansion shouldn't be able to insert, say, an \else > in a non-active branch? Maybe, but if it can insert an \else in an active > branch, then why not non-active too?

Re: [HACKERS] Improvements in psql hooks for variables

Tom Lane wrote: > "Daniel Verite" <dan...@manitou-mail.org> writes: > > [ psql-var-hooks-v6.patch ] > > I took a quick look through this. It seems to be going in generally > the right direction, but here's a couple of thoughts: Thanks for looking in

Re: [HACKERS] Improvements in psql hooks for variables

Ashutosh Sharma wrote: > postgres=# \echo :ENCODING > UTF8 > postgres=# \set ENCODING xyz > postgres=# \echo :ENCODING > xyz > > I think currently we are not even showing what are the different valid > encoding names to the end users like we show it for other built-in > variables >

  1   2   >