Skip site navigation (1) Skip section navigation (2)

Re: tuple count and v3 functions in psql for COPY

From: Volkan YAZICI <yazicivo(at)ttnet(dot)net(dot)tr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: tuple count and v3 functions in psql for COPY
Date: 2005-12-22 19:48:13
Message-ID: 20051222194813.GA2266@alamut (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
On Dec 22 01:52, Tom Lane wrote:
> > !             {
> > !                 uint64    processed = DoCopy((CopyStmt *) parsetree);
> > !                 char    buf[21];
> > ! 
> > !                 snprintf(buf, sizeof(buf), UINT64_FORMAT, processed);
> > !                 snprintf(completionTag, COMPLETION_TAG_BUFSIZE,
> > !                          "COPY %s", buf);
> > !             }
> This is ugly and unnecessary.  Why not
> > !             {
> > !                 uint64    processed = DoCopy((CopyStmt *) parsetree);
> > ! 
> > !                 snprintf(completionTag, COMPLETION_TAG_BUFSIZE,
> > !                          "COPY " UINT64_FORMAT, processed);
> > !             }

At the beginning I used the style as above, but after looking at the
source code for INT64_FORMAT usage, saw that nearly all of them use
a seperate buffer.

Furthermore, in the source code (for instance
backend/commands/sequence.c) nearly every buffer size used for
INT64_FORMAT is 100. AFAIK, 20+1 is enough for a 64 bit integer.

> Also, I think you've broken the psql-side handling of COPY IN.  There's
> no check for I/O error on the input, and the test for terminator (\.\n)
> mistakenly assumes that the terminator could only appear at the start
> of the buffer, not to mention assuming that it couldn't span across two
> bufferloads.
> The check for \r is wrong too (counterexample: first input line exceeds
> 8K), but actually you should just dispense with that entirely, because
> if you're going to use PQputCopyEnd then it is not your responsibility
> to send the terminator.
> But the *real* problem with this coding is that it will fetch data past
> the \., which breaks files that include both COPY data and SQL.  Thus
> for example this patch breaks pg_dump files.

8K limit is caused by a mis-understanding of me. Thanks so much for the
review, I'll try to fix above missing parts ASAP.

> ! 	for (c = p; isdigit((int) *c); ++c)
> Wrong.  Use (unsigned char).

I found above from "The Open Group Base Specifications Issue 6". I'll
fix that too.


"We are the middle children of history, raised by television to believe
that someday we'll be millionaires and movie stars and rock stars, but
we won't. And we're just learning this fact," Tyler said. "So don't
fuck with us."

In response to

pgsql-patches by date

Next:From: Bruce MomjianDate: 2005-12-22 23:09:49
Subject: Re: [PATCHES] [BUGS] Solaris cc compiler on amd: PostgreSQL does not
Previous:From: Tom LaneDate: 2005-12-22 18:52:56
Subject: Re: tuple count and v3 functions in psql for COPY

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group