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
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
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
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
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
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
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:
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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,
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
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
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
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
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
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
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
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,
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:
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
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.
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
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
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
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,
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
>
>
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
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
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
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
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
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:
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
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
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
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.)
>
>
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
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
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,
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,
> >>
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
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
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
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
>
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.
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
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
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
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
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
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
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.
-
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
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
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
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
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.
-
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
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:
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
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
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?
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
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 - 100 of 174 matches
Mail list logo