"Daniel Verite" writes:
> Tom Lane wrote:
>> Returning to my upthread thought that
>>> I think we should fix it so that \. that's not alone on a line
>>> throws an error, but I wouldn't go further than that.
>> here's a quick follow-on patch to make that happen. It could
>> probably do with a tes
Tom Lane wrote:
> > [ v6-0001-Support-backslash-dot-on-a-line-by-itself-as-vali.patch ]
>
> I did some more work on the docs and comments, and pushed that.
Thanks!
> Returning to my upthread thought that
>
> >>> I think we should fix it so that \. that's not alone on a line
> >>> throw
"Daniel Verite" writes:
> [ v6-0001-Support-backslash-dot-on-a-line-by-itself-as-vali.patch ]
I did some more work on the docs and comments, and pushed that.
Returning to my upthread thought that
>>> I think we should fix it so that \. that's not alone on a line
>>> throws an error, but I would
Artur Zakirov wrote:
> I've tested the patch and it seems it works as expected.
Thanks for looking at this!
> It seems it isn't necessary to handle "\." within
> "CopyAttributeOutCSV()" (file "src/backend/commands/copyto.c")
> anymore.
It's still useful to produce CSV data that can be s
"Daniel Verite" writes:
> To clarify the compatibility issue, the attached bash script
> compares pre-patch and post-patch client/server combinations with
> different cases, submitted with different copy variants.
> ...
> Also attaching the tables of results with the patch as it stands.
> "Failed"
On Wed, 31 Jul 2024 at 15:42, Daniel Verite wrote:
>
> Sutou Kouhei wrote:
>
> > BTW, here is a diff after pgindent:
>
> PFA a v5 with the cosmetic changes applied.
Thank you Daniel for working on it. I've tested the patch and it seems
it works as expected.
I have a couple of minor comme
Hi,
In <4ffb7317-7e92-4cbd-a542-1e478af6a...@manitou-mail.org>
"Re: Fixing backslash dot for COPY FROM...CSV" on Wed, 31 Jul 2024 15:42:41
+0200,
"Daniel Verite" wrote:
>> BTW, here is a diff after pgindent:
>
> PFA a v5 with the cosmetic changes a
Sutou Kouhei wrote:
> BTW, here is a diff after pgindent:
PFA a v5 with the cosmetic changes applied.
> I also confirmed that the updated server and non-updated
> psql compatibility problem (the end-of-data "\." is
> inserted). It seems that it's difficult to solve without
> introducing
Sutou Kouhei writes:
> I read through this thread. It seems that this thread
> discuss 2 things:
> 1. \. in CSV mode
> 2. \. in non-CSV mode
> Recent messages discussed mainly 2. but how about create a
> separated thread for 2.? Because the original mail focused
> on 1. and it seems that we can ha
Fixing backslash dot for COPY FROM...CSV" on Sun, 07 Apr 2024 00:07:13
-0400,
Tom Lane wrote:
> Here's the problem: if some client-side code thinks it's okay to
> quote "." as "\.", what is likely to happen when it's presented
> a data value cons
Bruce Momjian writes:
> On Sun, Apr 7, 2024 at 12:00:25AM +0200, Daniel Verite wrote:
>> Agreed we don't want to document that, but also why doesn't \. in the
>> contents represent just a dot (as opposed to being an error),
>> just like \a is a?
> I looked into this and started to realize that
On Sun, Apr 7, 2024 at 12:00:25AM +0200, Daniel Verite wrote:
> Tom Lane wrote:
>
> > This is sufficiently weird that I'm starting to come around to
> > Daniel's original proposal that we just drop the server's recognition
> > of \. altogether (which would allow removal of some dozens of li
Tom Lane wrote:
> This is sufficiently weird that I'm starting to come around to
> Daniel's original proposal that we just drop the server's recognition
> of \. altogether (which would allow removal of some dozens of lines of
> complicated and now known-buggy code)
FWIW my plan was to not
I wrote:
> So the current behavior is that \. that is on the end of a line,
> but is not the whole line, is silently discarded and we keep going.
> All versions throw "end-of-copy marker corrupt" if there is
> something after \. on the same line.
> This is sufficiently weird that I'm starting to
After some more poking at this topic, I realize that there is already
very strange and undocumented behavior for backslash-dot even in
non-CSV mode. Create a file like this:
$ cat eofdata
foobar
foobaz\.
more
\.
yet more
and try importing it with COPY:
regression=# create table eofdata(f1 text)
"Daniel Verite" writes:
> Tom Lane wrote:
>> Not sure what to do here. One idea is to install just the psql-side
>> fix, which should break nothing now that version-2 protocol is dead,
>> and then wait a few years before introducing the server-side change.
>> That seems kind of sad though.
Tom Lane wrote:
> Not sure what to do here. One idea is to install just the psql-side
> fix, which should break nothing now that version-2 protocol is dead,
> and then wait a few years before introducing the server-side change.
> That seems kind of sad though.
Wouldn't backpatching solve
I wrote:
> So this means that the patch introduces a rather serious cross-version
> compatibility problem. I doubt we can consider inlined CSV data to be
> a niche case that few people use; but it will fail every time if your
> psql is older than your server.
On third thought, that may not be as
"Daniel Verite" writes:
> Tom Lane wrote:
>> I've looked over this patch and I generally agree that this is a
>> reasonable solution.
> Thanks for reviewing this!
While testing this, I tried running the tests with an updated server
and non-updated psql, and not only did the new test case f
Tom Lane wrote:
> I've looked over this patch and I generally agree that this is a
> reasonable solution.
Thanks for reviewing this!
> I'm also wondering why the patch adds a test for
> "PQprotocolVersion(conn) >= 3" in handleCopyIn.
I've removed this in the attached update.
> I concu
"Daniel Verite" writes:
> Robert Haas wrote:
>> Those links unfortunately seem not to be entirely specific to this
>> issue. Other, related things seem to be discussed there, and it's not
>> obvious that everyone agrees on what to do, or really that anyone
>> agrees on what to do.
> The pro
Robert Haas wrote:
> Those links unfortunately seem not to be entirely specific to this
> issue. Other, related things seem to be discussed there, and it's not
> obvious that everyone agrees on what to do, or really that anyone
> agrees on what to do. The best link that I found for this ex
Robert Haas wrote:
> Part of my hesitancy, I suppose, is that I don't
> understand why we even have this strange convention of making \.
> terminate the input in the first place -- I mean, why wouldn't that be
> done in some kind of out-of-band way, rather than including a special
> marker
On Mon, Dec 18, 2023 at 3:36 PM Daniel Verite wrote:
> PFA a patch that attempts to fix the bug that \. on a line
> by itself is handled incorrectly by COPY FROM ... CSV.
> This issue has been discussed several times previously,
> for instance in [1] and [2], and mentioned in the
> doc for \copy i
Hi,
The CI patch tester fails on this patch, because it has a label
at the end of a C block, which I'm learning is a C23 feature
that happens to be supported by gcc 11 [1], but is not portable.
PFA an update fixing this, plus removing an obsolete chunk
in the COPY documentation that v2 left out
On Fri, 22 Dec 2023 at 01:17, Daniel Verite wrote:
>
> vignesh C wrote:
>
> > Thanks for the updated patch, any reason why this is handled only in csv.
> > postgres=# copy test1 from '/home/vignesh/postgres/inst/bin/copy1.out';
> > COPY 1
> > postgres=# select * from test1;
> > c1
> > ---
vignesh C wrote:
> Thanks for the updated patch, any reason why this is handled only in csv.
> postgres=# copy test1 from '/home/vignesh/postgres/inst/bin/copy1.out';
> COPY 1
> postgres=# select * from test1;
> c1
> ---
> line1
> (1 row)
I believe it's safer to not change anything t
On Tue, 19 Dec 2023 at 16:57, Daniel Verite wrote:
>
> vignesh C wrote:
>
> > I noticed that these tests are passing without applying patch too:
>
> > +insert into copytest2(test) values('line1'), ('\.'), ('line2');
> > +copy (select test from copytest2 order by test collate "C") to :'file
vignesh C wrote:
> I noticed that these tests are passing without applying patch too:
> +insert into copytest2(test) values('line1'), ('\.'), ('line2');
> +copy (select test from copytest2 order by test collate "C") to :'filename'
> csv;
> +-- get the data back in with copy
> +truncate co
On Tue, 19 Dec 2023 at 02:06, Daniel Verite wrote:
>
> Hi,
>
> PFA a patch that attempts to fix the bug that \. on a line
> by itself is handled incorrectly by COPY FROM ... CSV.
> This issue has been discussed several times previously,
> for instance in [1] and [2], and mentioned in the
> doc f
Hi,
PFA a patch that attempts to fix the bug that \. on a line
by itself is handled incorrectly by COPY FROM ... CSV.
This issue has been discussed several times previously,
for instance in [1] and [2], and mentioned in the
doc for \copy in commit 42d3125.
There's one case that works today: whe
31 matches
Mail list logo
