On Wed, Jan 30, 2019 at 01:20:59PM -0500, Tom Lane wrote:
> Given how long we've had COPY CSV support, and the tiny number of
> complaints to date, I do not think it's something to panic over.
> Disallowing the functionality altogether is surely an overreaction.
>
> A documentation warning might be
Pavel Stehule writes:
> st 30. 1. 2019 18:51 odesÃlatel Bruce Momjian napsal:
>> I am wondering if we should just disallow CSV from STDIN, on security
>> grounds. How big a problem would that be for people? Would we have to
>> disable to STDOUT as well since it could not be restored? Should we
st 30. 1. 2019 18:51 odesÃlatel Bruce Momjian napsal:
> On Wed, Jan 30, 2019 at 06:32:11PM +0100, Daniel Verite wrote:
> > Bruce Momjian wrote:
> > > Well, these all kind of require a change to the COPY format, which
> > > hasn't changed in many years.
> >
> > Not for the first two. As an e
On Wed, Jan 30, 2019 at 06:32:11PM +0100, Daniel Verite wrote:
> Bruce Momjian wrote:
> > Well, these all kind of require a change to the COPY format, which
> > hasn't changed in many years.
>
> Not for the first two. As an example of solution #2, it could look like this:
>
> =# \set INLINE
Bruce Momjian wrote:
> > - the end of data could be expressed as a length (in number of lines
> > for instance) instead of an in-data marker.
> >
> > - the end of data could be configurable, as in the MIME structure of
> > multipart mail messages, where a part is ended by a "boundary",
>
On Mon, Jan 28, 2019 at 04:06:17PM +0100, Daniel Verite wrote:
> Michael Paquier wrote:
>
> > In src/bin/psql/copy.c, handleCopyIn():
> >
> > /*
> > * This code erroneously assumes '\.' on a line alone
> > * inside a quoted CSV string terminates the \copy.
> > *
> > http://www.postgresql.or
On Fri, Jan 25, 2019 at 01:01:22PM +0100, Daniel Verite wrote:
> Bruce Momjian wrote:
>
> > but I am able to see the failure using STDIN:
> >
> > COPY test FROM STDIN CSV;
> > Enter data to be copied followed by a newline.
> > End with a backslash and a period on a l
On Sun, Jan 27, 2019 at 10:10:36PM +0900, Michael Paquier wrote:
> On Thu, Jan 24, 2019 at 10:09:30PM -0500, Bruce Momjian wrote:
> > This seems like a bug to me. Looking at the code, psql issues the
> > prompts for STDIN, but when it sees \. alone on a line, it has no idea
> > you are in a quoted
Michael Paquier wrote:
> In src/bin/psql/copy.c, handleCopyIn():
>
> /*
> * This code erroneously assumes '\.' on a line alone
> * inside a quoted CSV string terminates the \copy.
> *
> http://www.postgresql.org/message-id/e1tdnvq-0001ju...@wrigleys.postgresql.org
> */
> if (strcmp(buf, "
On Thu, Jan 24, 2019 at 10:09:30PM -0500, Bruce Momjian wrote:
> This seems like a bug to me. Looking at the code, psql issues the
> prompts for STDIN, but when it sees \. alone on a line, it has no idea
> you are in a quoted CSV string, so it thinks the copy is done and sends
> the result to the
Bruce Momjian wrote:
> but I am able to see the failure using STDIN:
>
> COPY test FROM STDIN CSV;
> Enter data to be copied followed by a newline.
> End with a backslash and a period on a line by itself, or an EOF
> signal.
> "foo
> \.
> ER
On Wed, Jan 2, 2019 at 04:58:35PM +0100, Daniel Verite wrote:
> Hi,
>
> The doc on COPY CSV says about the backslash-dot sequence:
>
> To avoid any misinterpretation, a \. data value appearing as a
> lone entry on a line is automatically quoted on output, and on
> input, if quoted, is not
12 matches
Mail list logo
