> Otherwise "\g -" looks good as a portable solution.
+1
Tom Lane wrote:
> > Now as far as I can see, there is nothing that \copy to file or program
> > can do that COPY TO STDOUT cannot do.
>
> I don't think there's a way to get the effect of "\copy to pstdout"
> (which, IIRC without any caffeine, means write to psql's stdout regardless
> of w
"Daniel Verite" writes:
> Tom Lane wrote:
>> A variant that might or might not be safer is "\g > insist on you putting a mark there that shows you intended to read.
> I haven't written any patch yet, but I was thinking of submitting
> something like that, with the addition of "\g >foo" as a
Tom Lane wrote:
> A variant that might or might not be safer is "\g insist on you putting a mark there that shows you intended to read.
>
> Also, not quite clear what we'd do about copy-from-program.
> I think "\g |foo" is definitely confusing for that. "\g foo|"
> would be better if it
"Daniel Verite" writes:
> Now as far as I can see, there is nothing that \copy to file or program
> can do that COPY TO STDOUT cannot do.
I don't think there's a way to get the effect of "\copy to pstdout"
(which, IIRC without any caffeine, means write to psql's stdout regardless
of where queryFo
Tom Lane wrote:
> OK. I fixed the error-cleanup issue and pushed it.
>
> The patch applied cleanly back to 9.5, but the code for \g is a good
> bit different in 9.4. I didn't have the interest to try to make the
> patch work with that, so I just left 9.4 alone.
Thanks!
Now as far as I
Fabien COELHO writes:
>> It's unclear to me whether to push ahead with Daniel's existing
>> patch or not. It doesn't look to me like it's making things
>> any worse from the error-consistency standpoint than they were
>> already, so I'd be inclined to consider error semantics cleanup
>> as someth
Hello Tom,
Fixing the problem envolves deciding what is the right behavior, and
update the documentation and the implementation accordingly. Currently the
documentation suggests that :ERROR is about SQL error (subject to
interpretation), and the implementation is more or less consistent with
t
Fabien COELHO writes:
> Fixing the problem envolves deciding what is the right behavior, and
> update the documentation and the implementation accordingly. Currently the
> documentation suggests that :ERROR is about SQL error (subject to
> interpretation), and the implementation is more or less
Bonsoir Daniel,
Sure. As there are several bugs (doubtful features) uncovered, a first
patch could fix "COPY ...TO STDOUT \g file", but probably replicate ERROR
current behavior however debatable it is (i.e. your patch without the
ERROR change, which is unrelated to the bug being fixed), and t
Fabien COELHO wrote:
> Sure. As there are several bugs (doubtful features) uncovered, a first
> patch could fix "COPY ...TO STDOUT \g file", but probably replicate ERROR
> current behavior however debatable it is (i.e. your patch without the
> ERROR change, which is unrelated to the bug
BEGIN;
UPDATE pgbench_branches SET bbalance = bbalance + 1 RETURNING * \g /bad
// the update is performed, the transaction is not rollbacked,
// *but* the output file was not written, "COMMIT" save changes.
if PQexec() could not store the results for lack of memory, it would
yield a P
Fabien COELHO wrote:
> > Now if you download data with SELECT or COPY and we can't even
> > create the file, how is that a good idea to intentionally have the
> > script fail to detect it? What purpose does it satisfy?
>
> It means that the client knows that the SQL command, and possible
Bonsoir Daniel,
sql> SELECT 1 \g /BAD
/BAD: Permission denied
sql> \echo :ERROR
false
That seems broken, because it's pointless to leave out a class of errors
from ERROR.
Yep. That is my point, but fixing it requires to decide whether it is okay
to change ERROR documentation and
Fabien COELHO wrote:
> (1) document ERROR as being muddy, i.e. there has been some error which
> may be SQL or possibly client side. Although SQLSTATE would still allow to
> know whether an SQL error occured, there is still no client side
> expressions, and even if I had moved pgbench e
Fabien COELHO wrote:
> sql> SELECT 1 \g /BAD
> /BAD: Permission denied
>
> sql> \echo :ERROR
> false
That seems broken, because it's pointless to leave out a class of errors
from ERROR. Presumably the purpose of ERROR is to enable
error checking like:
\if :ERROR
... error p
I understand from the code that the COPY is really executed, so the ERROR
and so ROW_COUNT about the SQL should reflect that. Basically the change
makes the client believe that there is an SQL error whereas the error is
on the client.
Right, but wether COPY fails because psql can't write the
Bonjour Daniel,
:ROW_COUNT is incorrect after COPY TO STDOUT but this is a PG11-only
bug, :ROW_COUNT being a recent addition, so maybe we should deal with
this separately, since the current patch is supposed to address all versions?
ISTM that the patch is considered a bug fix, so it shoud be
Fabien COELHO wrote:
> > I've also changed handleCopyOut() to return success if it
> > could pump the data without writing it out locally for lack of
> > an output stream. It seems to make more sense like that.
>
> I'm hesitating on this one.
>
> On the one hand the SQL query is executed
Bonjour Daniel,
I took a quick look at this patch.
PFA an updated patch addressing your comments and Fabien's.
About this v2.
Applies cleanly, compiles cleanly, "make check" ok.
No tests, but Tom suggests this does not belong here: the committer is
right:-)
I tested the feature manual
Tom Lane wrote:
> I took a quick look at this patch.
PFA an updated patch addressing your comments and Fabien's.
I've also changed handleCopyOut() to return success if it
could pump the data without writing it out locally for lack of
an output stream. It seems to make more sense like tha
I took a quick look at this patch. Some thoughts:
* I think the right way to proceed is to commit (and back-patch)
this without any regression test case, and maybe later look into
adding a TAP test that covers "\g file". We have no test cases
for any variant of "\g file", and because of platform
On 2018-Dec-27, Daniel Verite wrote:
>
> Maybe I misunderstand something, as I'm not familiar with TAP tests,
> but hasn't psql no such test to begin with, as opposed to the
> other programs in src/bin that have a t/ directory?
That's correct. psql does have some tests though, in
src/test/regre
Fabien COELHO wrote:
> Dunno. Even if an additional tap test would not be backpatched, it could
> be added on master. I'm basically sadden by pg test coverage, especially
> psql which is under 40%, so I try to grasp any improvement opportunity…
>
> See https://coverage.postgresql.org/
It looks a significant step forward, to be brought by a patch on its own
without prospect of being back-patched.
Dunno. Even if an additional tap test would not be backpatched, it could
be added on master. I'm basically sadden by pg test coverage, especially
psql which is under 40%, so I try
Fabien COELHO wrote:
> > It does not add "unless the query is a COPY", so it seems right
> > to make that just work, and call it a bug fix.
>
> Does this suggest backpatching?
Yes, I think it's a candidate for back-patching.
> > There is a precedent in regress/sql/hs_standby_allowed.sql
Hello,
Is this just kind of a bug fix? Beforehand the documentation says "\g fn"
sends to file, but that was not happening with COPY, and now it does as it
says?
Yes. [...]
It does not add "unless the query is a COPY", so it seems right
to make that just work, and call it a bug fix.
Does
Fabien COELHO wrote:
> Is this just kind of a bug fix? Beforehand the documentation says "\g fn"
> sends to file, but that was not happening with COPY, and now it does as it
> says?
Yes. The doc says about \g:
Sends the current query buffer to the server for execution. If an
argume
Bonjour Daniel,
But the copy-workflow and non-copy-workflow are different, and in
order to know which one to start, \g would need to analyze the query
It turns out I was wrong on this. The workflows are different but when
psql receives the first PGresult, it's still time to handle the I/O
re
"Daniel Verite" writes:
> So as a replacement for the \copyto I was proposing earlier, PFA a patch
> for COPY TO STDOUT to make use of the argument to \g.
Sounds plausible, please add to next commitfest so we don't forget it.
regards, tom lane
I wrote:
> I admit that if we could improve \g to handle COPY, it would be more
> elegant than the current proposal adding two meta-commands.
>
> But the copy-workflow and non-copy-workflow are different, and in
> order to know which one to start, \g would need to analyze the query
It tu
David G. Johnston wrote:
> POLA, for me at least, would be for \g [filename] to do exactly what
> you are describing with the \copyto feature.
I admit that if we could improve \g to handle COPY, it would be more
elegant than the current proposal adding two meta-commands.
But the copy-wor
On Fri, Nov 9, 2018 at 9:35 AM Daniel Verite wrote:
> If for instance psql received a notification between the two \o it would
> end up in the file, which it wouldn't with \copyto.
> The same is true for SELECT... \g file as opposed to \o file
Is that something we could change instead of adding
David G. Johnston wrote:
> Do I understand correctly that you are proposing a slightly less
> verbose alternative of:
>
> \o :filename
> COPY TO STDOUT
> \o
Not strictly the same because of this:
\o or \out [ filename ]
“Query results” includes all tables, command responses, and
On Fri, Nov 9, 2018 at 4:19 AM Daniel Verite wrote:
> Examples of use
>
> 1. $ psql -v filename="/path/data-$(date -I).csv"
> COPY (SELECT *
>FROM table
>WHERE ...)
> TO STDOUT (FORMAT csv) \copyto :filename
Do I understand correctly that you are proposing a slightly less
verbose alternat
Hi,
Currently \copy cannot span multiple lines (like any meta-command)
and cannot use psql variables whereas \g can do both.
The POC patch attached implements two meta-commands \copyfrom
and \copyto that are to COPY what \g is to any other query:
- they take the COPY query already var-expanded
36 matches
Mail list logo
