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 pg_read_bin
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 f
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 /lib/x86_64-linux-gnu/l
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
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
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 i
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 hstore/j
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, strin
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:
>
> Me
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 accep
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, for
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:
http://www.unicode.org/L2/L2000
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 abo
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. Column
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
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, sugge
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 docu
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 im
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
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 ☑
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 option
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 NULL
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, locale-aware,
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 c
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: http://ww
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 qu
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
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
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
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 e
Craig Ringer wrote:
> People won't see a README in amongst 5000 xlog segments while
> freaking out about the sever being down.
Maybe they're more likely to google "pg_xlog".
BTW, renaming it will not help with respect to that, as
there's a pretty good corpus on knowledge linked to that
pa
Joshua D. Drake wrote:
> You log in, see that all the space and you find that you are using a
> ton of disk space. You look around for anything you can delete. You
> find a directory called pg_xlog, it says log, junior ignorant, don't
> want to be a sysadmin 101 says, "delete logs".
Yes,
Rahila Syed wrote:
> >Above error coming because in below code block change, you don't have
> check for
> >command (you should check opt0 for AUTOCOMMIT command)
> Corrected in the attached.
There are other values than ON: true/yes and theirs abbreviations,
the value 1, and anything that
Rushabh Lathia wrote:
> It might happen that SetVariable() can be called from other places in
> future,
> so its good to have all the set variable related checks inside
> SetVariable().
There's already another way to skip the \set check:
select 'on' as "AUTOCOMMIT" \gset
But there's a
Craig Ringer wrote:
> Updated patch attached.
Please find attached a couple fixes for typos I've came across in
the doc part.
Also it appears that PQqueriesInBatch() doesn't work as documented.
It says:
"Returns the number of queries still in the queue for this batch"
but in fact it's i
Rahila Syed wrote:
> However, including the check here will require returning the status
> of command from this hook. i.e if we throw error inside this
> hook we will need to return false indicating the value has not changed.
Looking at the other variables hooks, they already emit errors
Tom Lane wrote:
> I think changing the hook API is a pretty reasonable thing to do here
> (though I'd make it its own patch and then add the autocommit change
> on top). When was the last time you actually wanted to set VERBOSITY
> to "fubar"?
It looks easy to make the hooks return a boo
Hi,
Following the discussion on forbidding an AUTOCOMMIT off->on
switch mid-transaction [1], attached is a patch that let the hooks
return a boolean indicating whether a change is allowed.
Using the hooks, bogus assignments to built-in variables can
be dealt with more strictly.
For example, pre
Rahila Syed wrote:
> I am beginning to review this patch. Initial comment. I got following
> compilation error when I applied the patch on latest sources and run make.
Sorry about that, I forgot to make clean, here's an updated patch.
Best regards,
--
Daniel Vérité
PostgreSQL-powered m
Ashutosh Bapat wrote:
> You may want to add this to the November commitfest
> https://commitfest.postgresql.org/11/.
Done. It's at https://commitfest.postgresql.org/11/799/
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
--
Tom Lane wrote:
> If we take this patch, what's to stop someone from complaining that we
> broke *their* badly-designed system that abuses the HOME variable?
POSIX warns against doing that, listing HOME in the variables that
should be left to their intended usage:
http://pubs.opengroup.or
Tomas Vondra wrote:
> 4) HandleParallelMessage needs a tweak, as it uses msg->len in a log
> message, but with '%d' and not '%ld' (as needed after changing the type
> to Size).
This could be %zu for the Size type. It's supported by elog().
However, it occurs to me that if we don't clai
Peter Eisentraut wrote:
> CREATE PROCEDURE pdrstest1()
> LANGUAGE SQL
> AS $$
> DECLARE c1 CURSOR WITH RETURN FOR SELECT * FROM cp_test2;
> DECLARE c2 CURSOR WITH RETURN FOR SELECT * FROM cp_test3;
> $$;
>
> CALL pdrstest1();
>
> and that returns those two result sets to the client.
If
Peter Eisentraut wrote:
> > CREATE PROCEDURE test()
> > LANGUAGE plpgsql
> > AS $$
> > RETURN QUERY EXECUTE 'SELECT 1 AS col1, 2 AS col2';
> > END;
> > $$;
> >
> > Or is that not possible or not desirable?
>
> RETURN means the execution ends there, so how would you return multiple
Tomas Vondra wrote:
> A few minor comments regarding the patch:
>
> 1) CopyStartSend seems pretty pointless - It only has one function call
> in it, and is called on exactly one place (and all other places simply
> call allowLongStringInfo directly). I'd get rid of this function and
>
Craig Ringer wrote:
> I think it's mostly of interest to app authors and driver developers
> and that's what it's aimed at. pg_restore could benefit a lot too.
Wouldn't pgbench benefit from it?
It was mentioned some time ago [1], in relationship to the
\into construct, how client-server
Gilles Darold wrote:
>postgres=# \setfileref b /dev/random
>postgres=# insert into test (:b);
>
> Process need to be killed using SIGTERM.
This can be fixed by setting sigint_interrupt_enabled to true
before operating on the file. Then ctrl-C would be able to cancel
the command.
Aleksander Alekseev wrote:
> According to my colleagues it would be very nice to have this feature.
> For instance, if you are trying to optimize PostgreSQL for application
> that uses COPY and you don't have access to or something like this.
> It could also be useful in some other cases.
Rahila Syed wrote:
> I have applied this patch on latest HEAD and have done basic testing which
> works fine.
Thanks for reviewing this patch!
> >if (current->assign_hook)
> >- (*current->assign_hook) (current->value);
> >- return true;
> >+
Hi,
I'm attaching v3 of the patch with error reporting for
FETCH_COUNT as mentioned upthread, and rebased
on the most recent master.
> I was suggesting change on the lines of extending generic_boolean_hook to
> include enum(part in enum_hooks which calls ParseVariableBool) and
> integer parsing
Corey Huinker wrote:
> I am not asking for this feature now, but do you see any barriers to later
> adding x/xq/xb/xbq equivalents for executing a shell command?
For text contents, we already have this (pasted right from the doc):
testdb=> \set content `cat my_file.txt`
testdb=> INSERT I
Tom Lane wrote:
> Stephen Frost writes:
> > In reviewing this patch, I also noticed that it's set up to assume a
> > 'true' result when a variable can't be parsed by ParseVariableBool.
>
> I suppose that's meant to be backwards-compatible with the current
> behavior:
>
> regression=# \t
Stephen Frost wrote:
> Just fyi, there seems to be some issues with this patch because setting
> my PROMPT1 and PROMPT2 variables result in rather odd behavior.
Good catch! The issue is that the patch broke the assumption
of prompt hooks that their argument points to a long-lived buffer.
Stephen Frost wrote:
> Are you working to make those changes? I'd rather we make the changes
> to this code once rather than push what you have now only to turn around
> and change it significantly again.
If, as a maintainer, you prefer this together in one patch, I'm fine
with that. So
Stephen Frost wrote:
> Are you working to make those changes? I'd rather we make the changes
> to this code once rather than push what you have now only to turn around
> and change it significantly again.
So I went through the psql commands which don't fail on parse errors
for booleans.
Stephen Frost wrote:
> That certainly doesn't feel right. I'm thinking that if we're going to
> throw an error back to the user about a value being invalid then we
> shouldn't change the current value.
>
> My initial thought was that perhaps we should pass the current value to
> ParseVar
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? See
Christoph Berg wrote:
> The new version tests \g and \gx with a new query, and
> re-running it on the last query buffer.
Thanks, here's a review:
The patch compiles and works as expected.
The code follows the same pattern as other one-shot command
modifiers, setting a flag in the global
Christoph Berg wrote:
> Both fixed, thanks for the review! Version 3 attached.
It looks good to me.
Stephen Frost is also reviewer on the patch, so I'm moving the
status back to "Needs review" at
https://commitfest.postgresql.org/13/973/
and let him proceed.
Best regards,
--
Daniel Vé
Vaishnavi Prabakaran wrote:
> Yes, I have created a new patch entry into the commitfest 2017-03 and
> attached the latest patch with this e-mail.
Please find attached a companion patch implementing the batch API in
pgbench, exposed as \beginbatch and \endbatch meta-commands
(without docum
Vaishnavi Prabakaran wrote:
>if (PQbatchStatus(st->con) != PQBATCH_MODE_ON)
>
>But, it is better to use if (PQbatchStatus(st->con) ==
> PQBATCH_MODE_OFF) for this verification. Reason is there is one more state
> in batch mode - PQBATCH_MODE_ABORTED. So, if the batch mode is in ab
Hi,
I notice that PQsetSingleRowMode() doesn't work when getting batch results.
The function is documented as:
" int PQsetSingleRowMode(PGconn *conn);
This function can only be called immediately after PQsendQuery or one
of its sibling functions, before any other operation on the connect
Vaishnavi Prabakaran wrote:
> > while (QbatchQueueProcess(conn)) {
> >r = PQsetSingleRowMode(conn);
> >if (r!=1) {
> > fprintf(stderr, "PQsetSingleRowMode() failed");
> >}
> >..
> Thanks for investigating the problem, and could you kindly exp
Tom Lane wrote:
> when we see \if is that we do nothing but absorb text
> until we see the matching \endif. At that point we could bitch and throw
> everything away if, say, there's \elif after \else, or anything else you
> want to regard as a "compile time error". Otherwise we start exe
Vaishnavi Prabakaran wrote:
> So, attached the alternative fix for this issue.
> Please share me your thoughts.
I assume you prefer the alternative fix because it's simpler.
> I would also like to hear Craig's opinion on it before applying this fix
> to the original patch, just to make s
Tom Lane wrote:
> OT_WHOLE_LINE is not what you want because that results in verbatim
> copying, without variable expansion or anything
But if we want to implement "\if defined :foo" in the future
isn't it just what we need?
Also we could leave open the option to accept an SQL expression
Vaishnavi Prabakaran wrote:
> Please let me know if you think this is not enough but wanted to update
> section 33.6 also?
Yes, if the right place to call PQsetSingleRowMode() is immediately
after PQbatchQueueProcess(), I think we need to update
"33.6. Retrieving Query Results Row-By-Row"
Vaishnavi Prabakaran wrote:
> Am going to include the test which you shared in the test patch. Please let
> me know if you want to cover anymore specific cases to gain confidence.
One bit of functionality that does not work in batch mode and is left
as is by the patch is the PQfn() fast p
Michael Paquier wrote:
> # Running: testlibpqbatch dbname=postgres 1 copyfailure
> dispatching SELECT query failed: cannot queue commands during COPY
>
> COPYBUF: 5
>
> Error status and message got from server due to COPY command failure
> are : PGRES_FATAL_ERROR ERROR: unexpected m
Vaishnavi Prabakaran wrote:
> Hmm, With batch mode, after sending COPY command to server(and server
> started processing the query and goes into COPY state) , client does not
> immediately read the result , but it keeps sending other queries to the
> server. By this time, server already en
Tom Lane wrote:
> Thoughts?
ISTM that expr is too painful to use to be seen as the
idiomatic way of achieving comparison in psql.
Among its disadvantages, it won't work on windows, and its
interface is hard to work with due to the necessary
quoting of half its operators, and the mandator
Hi,
I've noticed two issues with the query buffer post-commit e984ef5
(Support \if ... \elif ... \else ... \endif in psql scripting):
1. \p ignores the "previous buffer". Example:
postgres=# select 1;
?column?
--
1
(1 row)
postgres=# \p
Query buffer is empty.
That doesn't m
Fabien COELHO wrote:
> Note that this is already available indirectly, as show in the
> documentation.
>
> SELECT some-boolean-expression AS okay \gset
> \if :okay
> \echo boolean expression was true
> \else
> \echo boolean expression was false
> \endif
Yes, the question
Tom Lane wrote:
> > 1. \p ignores the "previous buffer". Example:
>
> Yeah, I did that intentionally, thinking that the old behavior was
> confusing. We can certainly discuss it though. I'd tend to agree
> with your point that \p and \w should print the same thing, but
> maybe neither o
Tom Lane wrote:
> If we do phrase it like that, I think that the most natural behavior
> for \r is the way I have it in HEAD --- you'd expect it to clear
> the query buffer, but you would not expect it to forget the most
> recent command.
Okay, leaving out \r as it is and changing only \p
Fabien COELHO wrote:
> My 0.02 € about server-side expressions: ISTM that there is nothing
> obvious/easy to do to include these:
>
> - how would it work, both with \set ... and \if ...?
The idea is that the need to have two command (a SELECT .. \gset
followed by an \if) and a tempora
Tom Lane wrote:
> I really dislike this syntax proposal. It would get us into having
> to count nested brackets, and distinguish quoted from unquoted brackets,
> and so on ... and for what? It's not really better than
>
> \if sql select 1 from pg_catalog.pg_extension where extname='pg
Hi,
In interactive mode, the warning in untaken branches is misleading
when \endif is on the same line as the commands that
are skipped. For instance:
postgres=# \if false \echo NOK \endif
\echo command ignored; use \endif or Ctrl-C to exit current \if block
postgres=#
From the point of
Fabien COELHO wrote:
> Now it could be decided that \set in psql stays simplistic because it is
> not needed as much as it is with pgbench. Fine with me.
It's not just that. It's that currently, if we do in psql:
\set d sqrt(1 + random(1000) * 17)
then we get that:
\echo :d
sqrt(1+ran
Fabien COELHO wrote:
> Pavel also suggested some support for TEXT, although I would like to see a
> use case. That could be another extension to the engine.
SQLSTATE is text.
Also when issuing "psql -v someoption=value -f script", it's reasonable
to want to compare :someoptionvar to 'so
Andres Freund wrote:
> FWIW, I still think this needs a pgbench or similar example integration,
> so we can actually properly measure the benefits.
Here's an updated version of the patch I made during review,
adding \beginbatch and \endbatch to pgbench.
The performance improvement appears
Craig Ringer wrote:
> The kernel will usually do some packet aggregation unless we use
> TCP_NODELAY (which we don't and shouldn't)
Not sure. As a point of comparison, Oracle has it as a tunable
parameter (TCP.NODELAY), and they changed its default from
No to Yes starting from their 10g R
Andres Freund wrote:
- if (pqFlush(conn) < 0)
- goto sendFailed;
+ if (conn->batch_status == PQBATCH_MODE_OFF)
+ {
+ /*
+* Give the data a push. In nonblock mode, don't complain if
we're unable
+* to send it all
Andres Freund wrote:
> > One option may be to leave that decision to the user by providing a
> > PQBatchAutoFlush(true|false) property, along with a PQBatchFlush()
> > function.
>
> What'd be the difference between PQflush() and PQbatchFlush()?
I guess no difference, I was just not seein
Fabien COELHO wrote:
>Fix psql \p to always print what would be executed by \g or \w (Daniel
>Vérité)
>
>Previously \p didn't properly print the reverted-to command after a
>buffer contents reset. CLARIFY?
>
> The fix is linked to the change introduced by Tom when
> refa
Pavel Stehule wrote:
> 1. using psql variables - we just need to write commands \setfrom
> \setfrombf - this should be very simple implementation. The value can be
> used more times. On second hand - the loaded variable can hold lot of
> memory (and it can be invisible for user).
This cou
Pavel Stehule wrote:
> It is similar to my first or second proposal - rejected by Tom :(
Doesn't it differ? ISTM that in the patches/discussion related to:
https://commitfest.postgresql.org/11/787/
it was proposed to change \set in one way or another,
and also in the point #1 of this pres
Surafel Temesgen wrote:
> I modified the patch as such and added to commitfest 2017-07.
A couple comments:
+ {"disallow_multiple_queries", PGC_POSTMASTER,
CLIENT_CONN_OTHER,
+ gettext_noop("Disallow multiple queries per query
string."),
+
Tom Lane wrote:
> Bearing in mind that I'm not really for this at all...
It's a band-aid, but certainly there are cases
where a DBA confronted to a badly written website
would just want to be able to:
ALTER USER webuser SET allow_multiple_queries TO off;
> But if an attacker is able to
Fabien COELHO wrote:
> I'm not fully convinced by this feature: using multiple queries is a
> useful trick to reduce network-related latency by combining several
> queries in one packet. Devs and even ORMs could use this trick.
It's proposed as an option. For apps that intentionally put
Andres Freund wrote:
> Since it's an application writer's choice whether to use it,
> it seems to make not that much sense to have a
> serverside guc - it can't really be sensible set.
The application writers who are concerned by this wouldn't
know that they have a choice. If there were i
Tom Lane wrote:
> Since we've blown past 80 columns on some of the other
> output, maybe that doesn't matter. Or maybe we should shorten this
> variable name so it doesn't force reformatting of all this text.
The two-space left margin on the entire block does not add that
much to readabi
Tomas Vondra wrote:
> That's not what I meant. I've never felt a strong urge to avoid wrapping
> at 80 chars when translating strings - simply translate in the most
> meaningful way, if it gets longer than 80 chars and can't be easily
> shortened, just wrap. If there are 60 or 80 character
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:
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 guy
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:
> 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 co
1 - 100 of 174 matches
Mail list logo
