Re: Alternative to \copy in psql modelled after \g - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: Alternative to \copy in psql modelled after \g
Date
Msg-id d51b800e-f169-43f4-bb61-e4cd88a5df32@manitou-mail.org
Whole thread Raw
In response to Re: Alternative to \copy in psql modelled after \g  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: Alternative to \copy in psql modelled after \g  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
    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 being fixed), and then another
> patch should fix/modify the behavior around ERROR (everywhere and
> consistently), and probably IMHO add an SQL_ERROR.

It's not as if the patch issued an explicit call SetVariable("ERROR", "true")
that could be commented, or something like that. The assignment
of the variable happens as a consequence of patched code that aims at
being correct in its error handling.
So I'm for leaving this decision to a maintainer, because I don't agree
with your conclusion that the current patch should be changed in
that regard.


Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Almost bug in COPY FROM processing of GB18030 encoded input
Next
From: Jesper Pedersen
Date:
Subject: Re: pg_upgrade: Pass -j down to vacuumdb