trivial or not the patch was broken. *sigh*. it's been a long day.
This patch will work.
sorry
andrew
RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/pg_dump.c,v
retrieving revision 1.335
diff -c -w -r1.335 pg_dump.c
*** pg_dump.c 25 Jun 2003 04:08:19 - 1.335
--- pg_dump.c
Finally I understand the issue, I think.
But wouldn't an ordinary user on SCO wanting to install a private copy of
Pg then have to hack the Makefiles to change/remove the abolute DT_SONAME?
If so, that seems to me to mandate that this not be in the vanilla
distribution. OS Vendors commonly make
I just noticed that the sample pg_hba.conf in the docs doesn't contain
any use of CIDR masks - here's a patch that adds a couple of sample
lines and associated comments.
Sorry for the lateness - I should have done this a month ago.
cheers
andrew
Index: client-auth.sgml
The attached patch does 3 things:
. logs connection ends if log_connections = true
. provides a new option log_line_format which allows addition of extra
information on a log line before the keyword. Currently supported are
user name and database name, but it is easily extensible. The string is
As discussed on Hackers.
enjoy
andrew
Index: doc/src/sgml/runtime.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.200
diff -c -w -r1.200 runtime.sgml
*** doc/src/sgml/runtime.sgml
only concern
was that the docs would give people info that would make things worse
rather than better, and nobody else was doing anything about it.
cheers
andrew
Neil Conway wrote:
Minor SGML gripes...
On Fri, Aug 22, 2003 at 10:00:00AM -0400, Andrew Dunstan wrote:
! To avoid
It appears we are back in the you need a non-empty password mode.
Anyway, here's the revised patch.
andrew
Andrew Dunstan wrote:
I didn't find a single instance of a warning tag in the doc sources.
I did find a warning in an unadorned para, in func.sgml.
Anyway, I made the changes (using
Here's a patch for pg_id.c that lets it compile
cleanly and run on Windows.
cheers
andrew
Index:
src/bin/pg_id/pg_id.c===RCS
file: /projects/cvsroot/pgsql-server/src/bin/pg_id/pg_id.c,vretrieving
revision 1.22.2.1diff -c -w
PROTECTED]
To: Andrew Dunstan [EMAIL PROTECTED]
Cc: PG Patches [EMAIL PROTECTED]
Sent: Sunday, October 05, 2003 12:17 AM
Subject: Re: [PATCHES] pg_id.c windows fix
Can you tell me what Win32 compile environment can't handle a sizeof()
as a function parameter?
! GetUserName(pw-pw_name, sizeof(pw
Bruce Momjian wrote:
Btw., I was wondering, are we kidding ourselves when we display
microsecond precision to the user? What accuracy do these measurements
have in respect to what they are actually supposed to measure?
Not sure. I think the microsecond stuff is accurate to some
This patch will stop gcc from issuing warnings
about type-punned objects when -fstrict-aliasing is turned on, as it is in the
latest gcc when you use -O2
enjoy
andrew
strict-alias.patch
Description: Binary data
---(end of broadcast)---
to contemplate that.
cheers
andrew
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Bruce Momjian [EMAIL PROTECTED]
Cc: Andrew Dunstan [EMAIL PROTECTED]; PG Patches
[EMAIL PROTECTED]
Sent: Saturday, October 11, 2003 1:29 PM
Subject: Re: [PATCHES] fix for strict-alias warnings
Bruce
Tom Lane wrote:
BTW, I haven't looked at the problem spots in detail. How many of them
are due to the use of MemSet in conjunction with other access to a chunk
of memory? ISTM that we need not worry about code motion around a
MemSet call, since that would require the compiler to prove that the
Andrew Dunstan wrote:
there were 3 calls to MemSet it complained about - all in
src/backend/storage/lmgr/proc.c, and all zeroing out the timeval
structure. (is MemSet actually a gain in this instance?)
And looking at it even closer, 2 of the 3 cases of calling MemSet appear
Peter Eisentraut wrote:
Andrew Dunstan writes:
And looking at it even closer, 2 of the 3 cases of calling MemSet appear
to be unnecessary, as the zeroed out values are immediately overwritten.
We need to zero out the holes in the structures so that hash functions
work correctly.
I
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, what gcc versions support -fno-strict-aliasing? Do we need a
configure test for it?
Perhaps ... although it is recognized in 2.95.3 and probably for a good
ways before that.
It looks to me like what has changed in gcc 3.3 is not
Spraul [EMAIL PROTECTED]
To: Tom Lane [EMAIL PROTECTED]
Cc: Andrew Dunstan [EMAIL PROTECTED]; Patches (PostgreSQL)
[EMAIL PROTECTED]
Sent: Tuesday, October 14, 2003 5:01 PM
Subject: Re: [PATCHES] fix for strict-alias warnings
Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
After
The attached patch limits parallelism for "make
check" on cygwin to 10 - meaning that at least on my installation "make check"
actually succeeds at last.
cheers
andrew
pg_regress.patch
Description: Binary data
---(end of broadcast)---
TIP
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Andrew Dunstan [EMAIL PROTECTED]
Cc: PG Patches [EMAIL PROTECTED]
Sent: Monday, October 27, 2003 11:12 PM
Subject: Re: [PATCHES] make check improvement for cygwin
Andrew Dunstan [EMAIL PROTECTED] writes:
Something like
Message -
From: Jason Tishler [EMAIL PROTECTED]
To: Andrew Dunstan [EMAIL PROTECTED]
Cc: PG Patches [EMAIL PROTECTED]
Sent: Wednesday, October 29, 2003 8:40 AM
Subject: Re: [PATCHES] make check improvement for cygwin
Andrew,
Something like this?
make MAX_CONNECTIONS=10 check
AFAICT
Jason Tishler wrote:
Andrew,
On Wed, Oct 29, 2003 at 08:45:30AM -0500, Andrew Dunstan wrote:
The number isn't hardcoded at all
Understood.
(except for the warning on gygwin if you choose some high value)
The above is my concern -- sorry, for being unclear.
I don't want to issue
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
It passes all the regression tests. I have also included a diff against
Andrew's version so you can see my changes. It seems Andrew had a very
current version of initdb. The only update he missed was the change to
test the number of
Bruce Momjian wrote:
It passes all the regression tests. I have also included a diff against
Andrew's version so you can see my changes. It seems Andrew had a very
current version of initdb. The only update he missed was the change to
test the number of connections before shared buffers ---
Bruce Momjian wrote:
Here is a slightly modified version of Andrew's great work in making a C
version of initdb. Other than minor cleanups, the only big change was
to remove rmdir handling because we using rm -r and rmdir /s in
commands/dbcommands.c, so we might as use the same thing for
Bruce Momjian wrote:
Yes, I was concerned too that everything was in there. I checked the
initdb.sh logs and found that the only thing not added was the checking
of the max number of connections before checking the max number of
buffers, which I added. The other stuff was in there. I also
Bruce Momjian wrote:
Andrew Dunstan wrote:
My comments:
I have no problem with shelling out to rmdir - although my goal was to
avoid shelling out to anything other than postgres itself. I think
recreating the datadir if we didn't create it initially should be OK in
that case
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Consider also the strong likelihood that the data directory's parent
directory is owned by root,
Again, this directory recreate happens only on Win32, an I thought it
would be OK there.
Windows has no concept of directory
Bruce Momjian wrote:
Also, I see this at the top of the code:
* author: Andrew Dunstan mailto:[EMAIL PROTECTED]
*
* Copyright (C) 2003 Andrew Dunstan
* Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group
* Portions
Bruce Momjian wrote:
I ran some tests using XP CMD and found:
C:\test
and
\test
works but:
test
does not work. Since I see that the output always has a leading path,
On Windows, pgpath is guaranteed to be a full path (see call to
expanded_path() ) exactly so it works
Apologies. Here's the patch. There may be other very minor differences
in wording, too. But if that's all I missed I won't think I did too
badly :-)
cheers
andrew
Tom Lane wrote:
What's become of initdb's initial note about who you are?
$ initdb
The files belonging to this database system
OK, this works.
cheers
andrew
Andrew Dunstan wrote:
ARRGGHH! It has a typo!. new patch shortly.
Andrew Dunstan wrote:
Apologies. Here's the patch. There may be other very minor
differences in wording, too. But if that's all I missed I won't think
I did too badly :-)
cheers
andrew
Tom
Note to self: stop working when brain is clearly malfunctioning.
*This* patch works. Please disregard previous.
thanks
andrew
Andrew Dunstan wrote:
OK, this works.
cheers
andrew
Andrew Dunstan wrote:
ARRGGHH! It has a typo!. new patch shortly.
Andrew Dunstan wrote:
? initdb
Index
darnit!
patch attached.
(Thinks - do we need to worry about suid sgid and sticky bits on data dir?)
andrew
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I just noticed tonight that the new initdb introduced a subtle change of
behavior. I use a shell script to automate the process
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
darnit!
patch attached.
Applied with correction (you got the return-value check backwards)
and further work to deal reasonably with error conditions occurring
in check_data_dir.
darnit again.
I'm taking a break - my head
That covers it extremely well.
cheers
andrew
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
At the time I wrote the original 2.6 was not out even in prerelease,
which is why I was deliberately somewhat vague about it. It is still in
prerelease, and it will in fact work slightly
Manfred Spraul wrote:
Tom Lane wrote:
Seriously though, if we can move the bulk of the writing work into
background processes then I don't believe that there will be any
significant penalty for regular backends. And I believe that it would
be a huge advantage from a correctness point of view
Bruce Momjian wrote:
I have grabbed code from NetBSD before, and I just mention that fact at
the top of the file. There is no need to repeat their license as it is
the same as our license.
I just added the last line:
* Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group
*
Neil Conway wrote:
To summarize, my understanding is that there are two problems:
(1) Some of the files in the main source tree are 4 clause
BSD. Since PostgreSQL is derived from these files, we fall
under its licensing restrictions, namely the advertising
clause.
I
heh. Now I can cross that off my todo list :-)
Euler Taveira de Oliveira wrote:
Hi,
I just enable support for internationalization of initdb. I used the same style from scripts. The files need to be put in initdb directory (nls.mk and po/pt_BR.po). The patch was made under CVS HEAD.
It just struck me that *maybe* a portable solution would be to put the
awk output inside genbki.sh in a .h file and then #include it in a one
line .c file which is passed to the preprocessor. Would that keep the
(strange) HP compiler happy?
cheers
andrew
ViSolve Open Source Team wrote:
**
Zach Irmen said:
Tom Lane [EMAIL PROTECTED] writes:
What happens if getenv(HOME) returns NULL?
Yeah, the strdup fails. I'll take it out to fix that.
You also need to think about Windows
Can I just ifndef WIN32 and not think about it? I'm not sure how that
would work either.
If we are
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I wrote:
There are a couple of other places where [select()] is used for small
sleeps (storage/lmgr/s_lock.c and access/transam/xact.c) -
What is the preferred way to handle these 2 cases? We could handle them
Claudio Natoli said:
patch + new file attached. Haven't tested on Windows, but
should be fine.
Would be, except for a small typo (conditional operator has an
additional : instead of a ?).
Darnit. please fix when applying.
Also, we might want to change to SleepEx,
depending on how we
Tom Lane said:
Peter Eisentraut [EMAIL PROTECTED] writes:
Jari Aalto wrote:
I made a mistake while running 7.4 under W2k/Cygwin, so perhaps the
patch would give user a little more comfort.
I don't see how. Please explain.
CVS-tip initdb seems to be written to suppress any trailing slash
This time it is my fault, rather than freebsd's ;-)
I think I can do something slightly cleaner than this, though, by
hoisting the buf termination above the test. We could also replace the
strncmp calls with strcmp calls if the buffer has its nul. I will post
something soon.
cheers
andrew
... and here it is. As for the test being outside the if statement, it
is true that that might waste a few cycles, but it hardly matters.
Personally, I would prefer to replace the if statement with this:
if (c == EOF || c == '\n')
{
*buf = '\0';
return;
}
and then it
OK, then *This* patch does it the way I think is clearest. Most of it is
just reindenting.
cheers
andrew
Dennis Bjorklund wrote:
On Sun, 1 Feb 2004, Andrew Dunstan wrote:
As for the test being outside the if statement, it is true that that
might waste a few cycles, but it hardly matters
Neil Conway wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
OK, then *This* patch does it the way I think is clearest. Most of it
is just reindenting.
Okay, I applied this patch, and made a few additional cleanups along
the way (the whole function and a couple other things don't need
This patch brings up to date what I did last year (now unfortunately
bitrotted) to allow the logging of the end of a session, enabled by the
config setting log_session_end - true. It produces lines like these:
for a local connection:
[21340] LOG: session end: duration: 0:00:23.41 user=andrew
Stephan Szabo wrote:
On Mon, 2 Feb 2004, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
I don't know of a memcpy() implementation that would actually bail out
if called with two equal pointers, but perhaps there is one in
existence somewhere.
This isn't a bug, and I see
Bruce Momjian wrote:
Neil Conway wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
In reading the patch, it seems he is only doing zero equals
unknown on Win32, so I think we are fine.
That's what I was trying to avoid: where possible, we shouldn't
introduce platform-dependent
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
After staring at the code for a long time, I think I see how to do
this. It's complicated a bit by the fact that $ is a valid
identifier character. So my current thinking is to say that if we
see
Tom Lane wrote:
A bigger problem here:
+ else if (!dol_quote line[i] == '$'
+ !isdigit(line[i + thislen])
+ (dol_end = strchr(line+i+1,'$')) != NULL
+ (i == 0 ||
+ ! ((line[i-1] 0x80) !=
just puts that function in mainloop.c, but
perhaps it belongs elsewhere (string_utils.c maybe?). I don't have
strong opinions on that.
Enjoy
andrew
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Comments welcome. Reviewers: I am not sure I got multi-byte stuff right
in psql
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I ended up not using a regex, which seemed to be a little heavy handed,
but just writing a small custom recognition function, that should (and I
think does) mimic the pattern recognition for these tokens used by the
backend lexer
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
... But how about
42$foo$
This is a syntax error in 7.4, and we propose to redefine it as an
integer literal '42' followed by a dollar-quote start symbol.
The test should not succeed anywhere
Attached is a patch for tagging log lines produced by backends. It is
not quite ready for application - this is for people to look over and
play with.
For my testing I used the following settings:
log_connections = true
log_disconnections = true
log_line_info = '%T [%P] [EMAIL
(Fourth try ;-)
Attached is a patch for dollar quoting in the backend and in psql (with
the new flex scanner). I'm fairly confident about the backend (because
this is mainly Tom's work adapted :-) ) but rather less so about psql -
I don't entirely understand all the odd states in psql's
Tom Lane wrote:
I think plpgsql's lexer also needs to be taught about dollar-quoting.
The attached patch appears to do the trick:
floobl=# create or replace function testme() returns text language
plpgsql as $$
floobl$# begin return $foo$a'\b$bar$foo$; end;
floobl$# $$;
CREATE
Bruce Momjian wrote:
+case 'C':
+ j += snprintf(result+j,result_len-j,%lx.%lx,
+(long)(MyProcPort-session_start.tv_sec),
+(long)MyProcPid);
One other comment. Are you sure you want a
Bruce Momjian wrote:
Andrew Dunstan wrote:
Attached is a patch for tagging log lines produced by backends. It is
not quite ready for application - this is for people to look over and
play with.
For my testing I used the following settings:
log_connections = true
log_disconnections = true
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Attached is a patch for tagging log lines produced by backends. It is
not quite ready for application - this is for people to look over and
play with.
For my testing I used the following settings:
log_connections = true
log_disconnections = true
Peter Eisentraut wrote:
Andrew Dunstan wrote:
I will do docs. We could sensibly get rid of log_pid and
log_timestamp with my latest patch. I would also suggest getting rid
of log_source_port, since there really isn't any reason *not* to log
the source port.
There is the very definite
There appears to be a missing row closing tag in funcs.sgml, which made
make html complain loudly for me. Fix below.
cheers
andrew
Index: func.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/func.sgml,v
retrieving
I think this is now ready for application, unless someone objects.
Since the last patch I posted, I have done the following:
. changed the escapes to lower case, as Peter prefers. This is also in
line with what Apache does, which is the nearest equivalent I can think of.
. added 2 new escapes:
Jon Jensen wrote:
On Sun, 29 Feb 2004, Andrew Dunstan wrote:
. changed source port reporting from host:port to host(port) to avoid
IP6 address ambiguity.
I have no idea how widespread this is, but recent versions of BIND write
it this way:
127.0.0.1#953
::1#953
Personally I'd kind
Tom Lane wrote:
The current definition of log_statement has no problem because we print
the whole string, once, before parsing starts. If you put a printout
into the per-parse-tree loop then I think you are going to get multiple
printouts of the same string.
I didn't intend to - I intended to
I believe that the attached patch may solve this setlocale() problem,
but I do not have a Windows box handy on which to test it. Can somebody
who does please try and let us know the results?
thanks
andrew
Andrew Dunstan wrote:
the answer is very probably here:
http
Bruce Momjian wrote:
Well, if that is the question, then I don't want to reorder the query
printout from the error.
OK. I'll let someone else do it. I have no need for it. Forget I spoke.
cheers
andrew
---(end of broadcast)---
TIP 8: explain
Bruce Momjian wrote:
Andrew Dunstan wrote:
Also, what is the default connection mode of psql? It should probably be
equivalent to -h localhost, shouldn't it?
Now that is something I had not thought of. Seems we can assume a Win32
psql can never use unix domain sockets, so defaulting
Patch attached. Also adds a malloc() check that Neil wanted.
cheers
andrew
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
*sigh*
my local (linux) man for gettimeofday says this:
struct timeval {
time_t tv_sec;/* seconds
Tom Lane wrote:
Please revise, and update the docs too.
Second attempt attached. The fatal message now reads no configured
listening socket available, but I am not wedded to the wording. I also
was not sure how to mark up * in the docs.
cheers
andrew
Index: doc/src/sgml/runtime.sgml
Magnus Hagander wrote:
This patch adds initial eventlog support on win32. It's good enough for
most purposes, but we will probably want a specific message DLL later to
format the messages nicer.
I'm extremely happy to see this being done - it's a must-have for WIN32,
I think.
The patch mimcs
Here's my attempt, as discussed earlier today. As always, comments
welcome. I did provide (and use) a fallback mechanism after all, for
the case of a function with a non-empty probin. A few examples from a
dump of the regression db:
--
-- Name: tg_hub_adjustslots(character, integer,
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Here's my attempt, as discussed earlier today. As always, comments
welcome. I did provide (and use) a fallback mechanism after all, for
the case of a function with a non-empty probin.
Applied with light
Bruce Momjian said:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Second attempt attached. The fatal message now reads no configured
listening socket available, but I am not wedded to the wording. I
also was not sure how to mark up * in the docs.
I went with no socket
Fabien COELHO wrote:
The last time I studied this stuff (which was quite a while back) the
follow set was something an LR parser generator would have to compute
anyway.
Yes.
I don't know whether bison's internal tables expose that set in any
useful fashion, but it surely seems worth a
Tom Lane wrote:
Fabien COELHO [EMAIL PROTECTED] writes:
(b) write a new recursive descendant parser, and drop gram.y
er, that's recursive descent :-)
Been there, done that, not impressed with the idea. There's a reason
why people invented parser generators...
Well, unless you are a
Unless I'm missing something, this patch has the effect that with values
of ddl or mod for log_statement, a statement with a parse error
will not be logged, which was what I hoped to avoid.
cheers
andrew
Bruce Momjian wrote:
Andrew Dunstan wrote:
Here are some options:
1. change
Bruce Momjian wrote:
Andrew Dunstan wrote:
Unless I'm missing something, this patch has the effect that with values
of ddl or mod for log_statement, a statement with a parse error
will not be logged, which was what I hoped to avoid.
Right. The query type can't be determined during
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Unless I'm missing something, this patch has the effect that with values
of ddl or mod for log_statement, a statement with a parse error
will not be logged, which was what I hoped to avoid
Bruce Momjian wrote:
Right now we have log_min_error_statement:
#log_min_error_statement = panic # Values in order of increasing severity:
# debug5, debug4, debug3, debug2, debug1,
# info,
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Right now we have log_min_error_statement:
#log_min_error_statement = panic # Values in order of increasing severity:
# debug5, debug4, debug3, debug2, debug1
Attached is an undocumented patch that implements COPY for CSVs
according to the scheme recently discussed. I believe it handles all the
straightforward and perverse cases that were discussed (including
multiline fields and partially quoted fields).
I have done some light testing on it, but
Andrew Dunstan wrote:
Attached is an undocumented patch that implements COPY for CSVs
according to the scheme recently discussed. I believe it handles all
the straightforward and perverse cases that were discussed (including
multiline fields and partially quoted fields).
I have done some
Fabien COELHO said:
My tests suggest that a feature of pg_restore is that it is only
expected to work with its own server. Indeed, it generates some new
syntax, such as $$ quoting, which is not compatible with older servers.
This fact does not seem to appear in the documentation.
Wrong. It
Andrew Dunstan wrote:
Andrew Dunstan wrote:
Attached is an undocumented patch that implements COPY for CSVs
according to the scheme recently discussed. I believe it handles all
the straightforward and perverse cases that were discussed (including
multiline fields and partially quoted fields
Fabien COELHO said:
Well, it means that you must decide a dump time if you may have to
restore in an older version. I can guess why it eased the
implementation, but it does not look good.
You want to be able to backup from version x to version y for some yx? We
support upgrades, not
Bruce Momjian wrote:
I have reviewed this patch. Basically, CSV is enabled by specifying
more than one delimiter character to COPY, e.g. DELIMITER ',' or
DELIMITER ','. Is this API good for folks?
(if not I'll be displeased, as it is what was the general consensus
about a month ago)
Prior
Bruce Momjian wrote:
Prior to 7.2, a multi-character delimiter could be specified, but only
the first character was used. 7.2 release notes state:
* COPY DELIMITERS string must be exactly one character (Tom)
I am a little worried about multibyte too, as you mentioned.
I am not
Tom Lane said:
COPY a FROM stdin WITH DELIMITER , QUOTE '' EQUOTE '';
EQUOTE for embedded quote.
ESCAPE would be better no? It's already a keyword ...
much better.
BTW, don't forget that the syntax options have to be provided in psql's
\copy as well. Did the patch cover that?
No,
Bruce Momjian said:
COPY tablename [ ( column [, ...] ) ]
TO { 'filename' | STDOUT }
[ [ WITH ]
[ BINARY ]
[ OIDS ]
[ DELIMITER [ AS ] 'delimiter' ]
[ NULL [ AS ] 'null string' ] ]
[
Bruce Momjian said:
Andrew Dunstan wrote:
Bruce Momjian said:
COPY tablename [ ( column [, ...] ) ]
TO { 'filename' | STDOUT }
[ [ WITH ]
[ BINARY ]
[ OIDS ]
[ DELIMITER [ AS ] 'delimiter
Bruce Momjian wrote:
It is my understanding that \N is a valid column value (no backslash
escape in CSV, right?), so we can't use it for NULL.
\ is not conventionally magical in CSVs in the general case. That
doesn't mean we couldn't use \N, but to me it would violate the
principle of least
Bruce Momjian wrote:
Andrew Dunstan wrote:
In fact, in the patch I sent in, no quoted string is marked as null when
being read (so even if you use \N as the null marker, \N will be that
literal and not a null marker). And the null marker, whatever it is,
should be made quote safe by us
Bruce Momjian said:
OK, here is a new version of the patch that includes the grammar changes
we agreed upon, SGML changes, and \copy support. I will not make any more
changes without contacting you so feel free to make adjustments and repost.
Excellent. Quick work :-) I will test later today.
Bruce Momjian said:
Second, I found a problem with NULLs. If I do:
.
test= create table test (x text, y text);
CREATE TABLE
test= insert into test values ('', NULL);
INSERT 17221 1
test=
then this:
test= copy test to '/tmp/b' with csv;
Andrew Dunstan wrote:
Bruce Momjian said:
Second, I found a problem with NULLs. If I do:
.
test= create table test (x text, y text);
CREATE TABLE
test= insert into test values ('', NULL);
INSERT 17221 1
test=
then this:
test= copy test to '/tmp/b' with csv
Bruno Wolff III wrote:
On Tue, Apr 13, 2004 at 06:58:24 -0400,
Andrew Dunstan [EMAIL PROTECTED] wrote:
One area that we should think about as an enhancement is NOT NULL fields.
As it stands now, we will get what we normally get when we try to insert
a null into a NOT NULL field, namely
Bruce Momjian wrote:
While doing OIDs seems atypical, it seems like a reasonable thing that
CSV should be able to do. Basically, I see no reason to disable it.
OK. We have bigger fish to fry ;-)
cheers
andrew
---(end of broadcast)---
TIP 9:
1 - 100 of 777 matches
Mail list logo
