[HACKERS] \copy (query) delimiter syntax error

2007-02-03 Thread Michael Fuhr
psql's \copy (query) with a delimiter yields a syntax error: test=> \copy foo to foo.txt delimiter '|' (works) test=> \copy (select * from foo) to foo.txt (works) test=> \copy (select * from foo) to foo.txt delimiter '|' ERROR: syntax error at or near "USING" LINE 1: COPY ( select

Re: [HACKERS] Referential Integrity and SHARE locks

2007-02-03 Thread Simon Riggs
On Fri, 2007-02-02 at 16:50 -0500, Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > On Fri, 2007-02-02 at 15:57 -0500, Tom Lane wrote: > >> , and it doesn't scale to > >> more than two holders, and I don't think it works for combinations of > >> share and exclusive lock. Also, what

Re: [HACKERS] \copy (query) delimiter syntax error

2007-02-03 Thread Andrew Dunstan
Michael Fuhr wrote: > psql's \copy (query) with a delimiter yields a syntax error: > > test=> \copy foo to foo.txt delimiter '|' > (works) > > test=> \copy (select * from foo) to foo.txt > (works) > > test=> \copy (select * from foo) to foo.txt delimiter '|' > ERROR: syntax error at or

Re: [HACKERS] \copy (query) delimiter syntax error

2007-02-03 Thread Michael Fuhr
On Sat, Feb 03, 2007 at 10:52:29AM -0600, Andrew Dunstan wrote: > I'd say fix psql. Not sure how far back we should backpatch it. It's > interesting that this has been there since 8.0 and is only now discovered. The problem is new in 8.2 because COPY (query) doesn't support USING DELIMITERS. COPY

Re: [HACKERS] Referential Integrity and SHARE locks

2007-02-03 Thread Stephan Szabo
On Sat, 3 Feb 2007, Simon Riggs wrote: > On Fri, 2007-02-02 at 16:50 -0500, Tom Lane wrote: > > No, I don't. I think knowledge of which columns are in a PK is quite a > > few levels away from the semantics of row locking. To point out just > > one problem, what happens when you add or drop a PK?

Re: [HACKERS] --enable-debug does not work with gcc

2007-02-03 Thread Matthias Luedtke
Hi all, Magnus Hagander wrote: Personally, in my development tree I use a Makefile.custom containing # back off optimization unless profiling ifeq ($(PROFILE),) CFLAGS:= $(patsubst -O2,-O1,$(CFLAGS)) endif -O1 still generates "uninitialized variable" warnings but the code is a lot saner to

Re: [HACKERS] \copy (query) delimiter syntax error

2007-02-03 Thread Andrew Dunstan
Michael Fuhr wrote: On Sat, Feb 03, 2007 at 10:52:29AM -0600, Andrew Dunstan wrote: I'd say fix psql. Not sure how far back we should backpatch it. It's interesting that this has been there since 8.0 and is only now discovered. The problem is new in 8.2 because COPY (query) doesn't s

Re: [HACKERS] Proposal: Commit timestamp

2007-02-03 Thread Jan Wieck
On 2/1/2007 11:23 PM, Jim Nasby wrote: On Jan 25, 2007, at 6:16 PM, Jan Wieck wrote: If a per database configurable tslog_priority is given, the timestamp will be truncated to milliseconds and the increment logic is done on milliseconds. The priority is added to the timestamp. This guarante

Re: [HACKERS] Proposal: Commit timestamp

2007-02-03 Thread Theo Schlossnagle
On Feb 3, 2007, at 3:52 PM, Jan Wieck wrote: On 2/1/2007 11:23 PM, Jim Nasby wrote: On Jan 25, 2007, at 6:16 PM, Jan Wieck wrote: If a per database configurable tslog_priority is given, the timestamp will be truncated to milliseconds and the increment logic is done on milliseconds. The p

Re: [HACKERS] --enable-debug does not work with gcc

2007-02-03 Thread Peter Eisentraut
Matthias Luedtke wrote: > And while we are at it, how about some CFLAGS="-DOPTIMIZER_DEBUG" > sweetness for the debugging section in the Dev FAQ? Most of the debugging macros are not documented because their purpose only arises out of the source code. -- Peter Eisentraut http://developer.postgr

Re: [HACKERS] Proposal: Commit timestamp

2007-02-03 Thread Jan Wieck
On 2/3/2007 4:05 PM, Theo Schlossnagle wrote: On Feb 3, 2007, at 3:52 PM, Jan Wieck wrote: On 2/1/2007 11:23 PM, Jim Nasby wrote: On Jan 25, 2007, at 6:16 PM, Jan Wieck wrote: If a per database configurable tslog_priority is given, the timestamp will be truncated to milliseconds and the inc

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-02-03 Thread Jan Wieck
Attached is the implementation of the proposed changes as a patch for discussion. The chosen syntax is backward compatible and uses ALTER TABLE ENABLE TRIGGER (fires on origin - default) ALTER TABLE DISABLE TRIGGER (disabled) ALTER TABLE ENABLE REPLICA TRIGGER (fires on replica only) ALTE

Re: [HACKERS] Proposal: Commit timestamp

2007-02-03 Thread Theo Schlossnagle
On Feb 3, 2007, at 4:38 PM, Jan Wieck wrote: On 2/3/2007 4:05 PM, Theo Schlossnagle wrote: On Feb 3, 2007, at 3:52 PM, Jan Wieck wrote: On 2/1/2007 11:23 PM, Jim Nasby wrote: On Jan 25, 2007, at 6:16 PM, Jan Wieck wrote: If a per database configurable tslog_priority is given, the timesta

Re: [HACKERS] Proposal: Commit timestamp

2007-02-03 Thread Jan Wieck
On 2/3/2007 4:58 PM, Theo Schlossnagle wrote: On Feb 3, 2007, at 4:38 PM, Jan Wieck wrote: On 2/3/2007 4:05 PM, Theo Schlossnagle wrote: On Feb 3, 2007, at 3:52 PM, Jan Wieck wrote: On 2/1/2007 11:23 PM, Jim Nasby wrote: On Jan 25, 2007, at 6:16 PM, Jan Wieck wrote: If a per database configu

Re: [HACKERS] Proposal: Commit timestamp

2007-02-03 Thread Theo Schlossnagle
On Feb 3, 2007, at 5:09 PM, Jan Wieck wrote: On 2/3/2007 4:58 PM, Theo Schlossnagle wrote: I don't have any such paper and the proof of concept will be the implementation of the system. I do however see enough resistance against this proposal to withdraw the commit timestamp at this time

Re: [HACKERS] Proposal: Commit timestamp

2007-02-03 Thread Bruce Momjian
Jan Wieck wrote: > I don't have any such paper and the proof of concept will be the > implementation of the system. I do however see enough resistance against > this proposal to withdraw the commit timestamp at this time. The new > replication system will therefore require the installation of a

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-02-03 Thread Joshua D. Drake
Jan Wieck wrote: > Attached is the implementation of the proposed changes as a patch for > discussion. > > The chosen syntax is backward compatible and uses > > ALTER TABLE ENABLE TRIGGER (fires on origin - default) > ALTER TABLE DISABLE TRIGGER (disabled) > ALTER TABLE ENABLE REPLICA TRIGGE

Re: [HACKERS] recovery.conf parsing problems

2007-02-03 Thread Bruce Momjian
Added to TODO: o Allow recovery.conf to allow the same syntax as postgresql.conf, including quoting http://archives.postgresql.org/pgsql-hackers/2006-12/msg00497.php --- Simon Riggs wrot

Re: [HACKERS] 8.1.5 release note

2007-02-03 Thread Bruce Momjian
Tatsuo Ishii wrote: > As usual, following item in the 8.1.5 release note is pretty vague: > > * Efficiency improvements in hash tables and bitmap index scans(Tom) > > Especially I'm wondering what was actually improved in bitmap index > scans. I see several commit messages regarding bitmap i

[HACKERS] SRF optimization question

2007-02-03 Thread Jeremy Drake
I am writing a set returning function in C. There are cases where I can know definitively, upfront, that this function will only return one row. I have noticed, through happenstance of partially converted function, that I can mark a normal, non-set returning function as returning SETOF something,

Re: [HACKERS] Dead code in _bt_split?

2007-02-03 Thread Bruce Momjian
Heikki, did this code cleanup get included in your recent btree split fix? --- Tom Lane wrote: > Heikki Linnakangas <[EMAIL PROTECTED]> writes: > > In that case, newitemleft would be false, right? > > I'm saying the piece ma

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-02-03 Thread Jan Wieck
On 2/3/2007 5:25 PM, Joshua D. Drake wrote: Jan Wieck wrote: Attached is the implementation of the proposed changes as a patch for discussion. The chosen syntax is backward compatible and uses ALTER TABLE ENABLE TRIGGER (fires on origin - default) ALTER TABLE DISABLE TRIGGER (disabled) ALT

[HACKERS] Remove log segment and log_id fields from pg_controldata

2007-02-03 Thread Bruce Momjian
The original discussion of this patch was here: http://archives.postgresql.org/pgsql-hackers/2006-11/msg00876.php Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the Post

Re: [HACKERS] psql possible TODO

2007-02-03 Thread Bruce Momjian
Added to TODO: o Add \# to list command history like \s, but with line numbers http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php --- Joshua D. Drake wrote: > Hello, > > O.k. this is my cu

Re: [PATCHES] [HACKERS] elog(FATAL)ing non-existent roles during client

2007-02-03 Thread Bruce Momjian
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Ga

Re: [HACKERS] "Compacting" a relation

2007-02-03 Thread Bruce Momjian
Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > vacuumlazy.c contains a hint "Consider compacting this relation" but > > AFAICT, > > there is no indication anywhere how "compacting" is supposed to be achieved. > > I guess this means VACUUM FULL or CLUSTER, but I don't think the

Re: [HACKERS] custom variable classes

2007-02-03 Thread Bruce Momjian
Added to TODO: * Allow custom variable classes that can restrict who can set the values http://archives.postgresql.org/pgsql-hackers/2006-11/msg00911.php --- Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writ

Re: [HACKERS] Proposal: Commit timestamp

2007-02-03 Thread Jan Wieck
On 2/3/2007 5:20 PM, Bruce Momjian wrote: Jan Wieck wrote: I don't have any such paper and the proof of concept will be the implementation of the system. I do however see enough resistance against this proposal to withdraw the commit timestamp at this time. The new replication system will ther

Re: [HACKERS] Referential Integrity and SHARE locks

2007-02-03 Thread Jan Wieck
On 2/2/2007 4:51 AM, Simon Riggs wrote: It sounds like if we don't put a SHARE lock on the referenced table then we can end the transaction in an inconsistent state if the referenced table has concurrent UPDATEs or DELETEs. BUT those operations do impose locking rules back onto the referencing ta