| From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
|---|---|
| To: | "Fabien COELHO" <coelho(at)cri(dot)ensmp(dot)fr> |
| Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com>,"PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>,"David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Subject: | Re: Alternative to \copy in psql modelled after \g |
| Date: | 2019-01-25 13:16:22 |
| Message-ID: | d51b800e-f169-43f4-bb61-e4cd88a5df32@manitou-mail.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jesper Pedersen | 2019-01-25 13:30:57 | Re: pg_upgrade: Pass -j down to vacuumdb |
| Previous Message | Heikki Linnakangas | 2019-01-25 12:56:27 | Re: Almost bug in COPY FROM processing of GB18030 encoded input |