Re: [HACKERS] RESET command seems pretty disjointed now

2007-04-17 Thread Marko Kreen
On 4/17/07, Tom Lane <[EMAIL PROTECTED]> wrote: Florian Pflug <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >>> The current documentation for RESET exhibits a certain lack of, um, >>> intellectual cohesiveness: > What about > RESET parameter > RESET { PLANS | TEMP | TEMPORARY } > RESET ALL { PAR

[HACKERS] modifying the table function

2007-04-17 Thread Islam Hegazy
Hi there I made some changes in postgresql source code to let the table function work in iteration fashion rather than materialization fashion. My main modifications are in 'exec_simple_query' function, I changed 'portalRunSelect' to return just one tuple instead of 'FETCH_ALL'. I made other va

Re: [HACKERS] modifying the table function

2007-04-17 Thread Tom Lane
"Islam Hegazy" <[EMAIL PROTECTED]> writes: > My question is how to inform the client that there is a tuple to display = > and return back to the backend to continue the query execution? I'd suggest you start by reading http://developer.postgresql.org/pgdocs/postgres/protocol.html and then develop

Re: [HACKERS] Hacking on PostgreSQL via GIT

2007-04-17 Thread Heikki Linnakangas
Chris Browne wrote: This strikes me as being a really super thing, having both Subversion and Git repositories publicly available that are tracking the PostgreSQL sources. Stepping back to the SCM discussion, people were interested in finding out what merits there were in having these sorts of S

[HACKERS] Buildfarm member Narwhal: Python 2.5/8.1

2007-04-17 Thread Dave Page
New buildfarm member Narwhal is failing the PL regression tests for Python on REL8_1_STABLE. This appears to be because it's running Python 2.5 (the causes being a deprecated module - whrandom - and some changed messages). The former problem was fixed by Peter, and the latter by Tom but both

Re: [HACKERS] Buildfarm member Narwhal: Python 2.5/8.1

2007-04-17 Thread Marko Kreen
On 4/17/07, Dave Page <[EMAIL PROTECTED]> wrote: New buildfarm member Narwhal is failing the PL regression tests for Python on REL8_1_STABLE. This appears to be because it's running Python 2.5 (the causes being a deprecated module - whrandom - and some changed messages). I also suggest backport

[HACKERS] Python test failures

2007-04-17 Thread Magnus Hagander
Hello! I'm trying to get the buildfarm to run on my XP x64 machine (still in 32-bit mode), and it's acting weird on me :-( The plpython tests because of: + NOTICE: ('import failed -- No module named bisect',) and ! ERROR: plpython: function "import_test_two" failed ! DETAIL: : No module named

Re: [HACKERS] Buildfarm member Narwhal: Python 2.5/8.1

2007-04-17 Thread Dave Page
Tom Lane wrote: Dave Page <[EMAIL PROTECTED]> writes: Andrew Dunstan wrote: The question in my mind is this: how much do we back-patch to cover new and incompatible releases of software we depend on? I guess that depends on the invasiveness - in this case it's a couple of simple updates to t

[HACKERS] Unhelpful debug tools on OS X :-(

2007-04-17 Thread Tom Lane
Dunno if anyone's noticed, but buildfarm member jackal has been crashing intermittently in the "cluster" regression test. I found out that I can reproduce that here on a Mac Mini (apparently the same or nearly same hardware/software as jackal) --- just repeat the parallel tests often enough, and i

Re: [HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)

2007-04-17 Thread KaiGai Kohei
Josh Berkus wrote: > KaiGai, > >> It provides database users fine grained mandatory access control >> including row and column level one, and integration with operating >> system security policy. > > Column level? We don't currently support that, except through VIEWs. > How is it implemented? P

Re: [HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)

2007-04-17 Thread KaiGai Kohei
Tom Lane wrote: > Josh Berkus <[EMAIL PROTECTED]> writes: >> Column level? We don't currently support that, except through VIEWs. >> How is it implemented? > > It wasn't clear to me how much of this is actually working today and how > much is a paper design --- one thing in particular that stood

Re: [HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)

2007-04-17 Thread KaiGai Kohei
Tom Lane wrote: > "Andrew Dunstan" <[EMAIL PROTECTED]> writes: >> What's more, we have a SoC project for column level access controls. > > ... which presumably wouldn't involve any added dependency on outside code. > For people who are already using SELinux or Trusted Solaris, making the > databas

Re: [HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)

2007-04-17 Thread KaiGai Kohei
For people who are already using SELinux or Trusted Solaris, making the database dependent on that infrastructure might be seen as a plus, but I'm not sure the rest of the world would be pleased. Even where SELinux is available it has had mixed reviews - I habitually disable it. The relatio

Re: [HACKERS] RESET command seems pretty disjointed now

2007-04-17 Thread Marko Kreen
On 4/17/07, Marko Kreen <[EMAIL PROTECTED]> wrote: If DISCARD is the final word, I start to prepare a patch. Attached patch does following conversions: RESET PLANS -> DISCARD PLANS RESET TEMP -> DISCARD TEMP RESET SESSION -> DISCARD ALL -- marko discard.diff.gz Description: GNU Zip compress

Re: [HACKERS] Buildfarm member Narwhal: Python 2.5/8.1

2007-04-17 Thread Tom Lane
Dave Page <[EMAIL PROTECTED]> writes: > Andrew Dunstan wrote: >> The question in my mind is this: how much do we back-patch to cover new >> and incompatible releases of software we depend on? > I guess that depends on the invasiveness - in this case it's a couple of > simple updates to the regre

Re: [HACKERS] Buildfarm member Narwhal: Python 2.5/8.1

2007-04-17 Thread Andrew Dunstan
Dave Page wrote: New buildfarm member Narwhal is failing the PL regression tests for Python on REL8_1_STABLE. This appears to be because it's running Python 2.5 (the causes being a deprecated module - whrandom - and some changed messages). The former problem was fixed by Peter, and the latter

Re: [HACKERS] Buildfarm member Narwhal: Python 2.5/8.1

2007-04-17 Thread Dave Page
Andrew Dunstan wrote: The question in my mind is this: how much do we back-patch to cover new and incompatible releases of software we depend on? Python 2.5 was released on 19 Sept 2006, long after Postgres 8.1. I guess you could make a case to say that we should back-patch to the release immed

Re: [HACKERS] Unhelpful debug tools on OS X :-(

2007-04-17 Thread Stefan Kaltenbrunner
Tom Lane wrote: > Dunno if anyone's noticed, but buildfarm member jackal has been crashing > intermittently in the "cluster" regression test. I found out that I can > reproduce that here on a Mac Mini (apparently the same or nearly same > hardware/software as jackal) --- just repeat the parallel t

[HACKERS] utf8 COPY DELIMITER?

2007-04-17 Thread Mark Dilger
The \COPY command rejects multibyte delimiters. Is this intentional behavior? Here is an example of the behavior: [EMAIL PROTECTED] ~ $ touch foo [EMAIL PROTECTED] ~ $ psql -p Welcome to psql 8.3devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \

Re: [HACKERS] utf8 COPY DELIMITER?

2007-04-17 Thread Andrew Dunstan
Mark Dilger wrote: The \COPY command rejects multibyte delimiters. Is this intentional behavior? It is certainly a known limitation, and I suspect removing it could add non-trivial overhead to the input processing. What is the use case for using such a delimiter? cheers andrew -

Re: [HACKERS] utf8 COPY DELIMITER?

2007-04-17 Thread Mark Dilger
Andrew Dunstan wrote: Mark Dilger wrote: The \COPY command rejects multibyte delimiters. Is this intentional behavior? It is certainly a known limitation, and I suspect removing it could add non-trivial overhead to the input processing. What is the use case for using such a delimiter? I'

Re: [HACKERS] utf8 COPY DELIMITER?

2007-04-17 Thread Andrew Dunstan
Mark Dilger wrote: Andrew Dunstan wrote: Mark Dilger wrote: The \COPY command rejects multibyte delimiters. Is this intentional behavior? It is certainly a known limitation, and I suspect removing it could add non-trivial overhead to the input processing. What is the use case for using su

Re: [HACKERS] utf8 COPY DELIMITER?

2007-04-17 Thread Tom Lane
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Mark Dilger wrote: >> I'm working on fixing bugs relating to multibyte character encodings. >> I wasn't sure whether this was a bug or not. I don't think we should >> use the phrasing "COPY delimiter must be a single character" when, in >> utf8 lan

Re: [HACKERS] utf8 COPY DELIMITER?

2007-04-17 Thread Tom Lane
On looking at the code, there's another issue: the CSV escape and quote characters are assumed to be the same in client and server encodings, because they're checked for before we do transcoding. This pretty much restricts them to be ASCII. regards, tom lane -

Re: [HACKERS] Autovacuum vs statement_timeout

2007-04-17 Thread Jim C. Nasby
On Sun, Apr 01, 2007 at 12:36:01AM +0200, Peter Eisentraut wrote: > Tom Lane wrote: > > I seem to remember that we'd agreed that autovacuum should ignore any > > globally set statement_timeout, on the grounds that a poorly chosen > > setting could indefinitely prevent large tables from being vacuum

Re: [HACKERS] Autovacuum vs statement_timeout

2007-04-17 Thread Joshua D. Drake
Jim C. Nasby wrote: On Sun, Apr 01, 2007 at 12:36:01AM +0200, Peter Eisentraut wrote: Tom Lane wrote: I seem to remember that we'd agreed that autovacuum should ignore any globally set statement_timeout, on the grounds that a poorly chosen setting could indefinitely prevent large tables from be

[HACKERS] schema creation during initdb

2007-04-17 Thread sharath kumar
How can I create a schema during initdb time? For example pg_catalog, pg_toast, information_schema are created during initdb time. Likewise I want to create my own schema at initdb time. How can i do it? Also how to create a table into this schema at that time itself? Thanks Sharat.

Re: [HACKERS] schema creation during initdb

2007-04-17 Thread Andrew Dunstan
sharath kumar wrote: How can I create a schema during initdb time? For example pg_catalog, pg_toast, information_schema are created during initdb time. Likewise I want to create my own schema at initdb time. How can i do it? Also how to create a table into this schema at that time itself?

Re: [HACKERS] Unhelpful debug tools on OS X :-(

2007-04-17 Thread Heikki Linnakangas
Tom Lane wrote: Any suggestions how to extract some info out of this? Does OS X have the catchsegv tool? If you can run postmaster with that, you should get a backtrace when it crashes. Unless it has the same problem as gdb, of course.. -- Heikki Linnakangas EnterpriseDB http://www.en

Re: [HACKERS] Unhelpful debug tools on OS X :-(

2007-04-17 Thread Tom Lane
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Any suggestions how to extract some info out of this? > Does OS X have the catchsegv tool? No, but I suddenly remembered about CrashReporter, and sure enough it's catching these crashes: Exception: EXC_BAD_ACCESS (0x0001) Codes

Re: [HACKERS] CREATE DATABASE foo OWNER bar

2007-04-17 Thread Bruce Momjian
Alvaro Herrera wrote: > Larry Rosenman wrote: > > Greetings, > > I think I found a bug, or at least a POLA violation. At work, I created > > a user that is NOT a superuser, nor can that user create databases. When I > > did a create database foo owner bar, all the schemas are set to be owned

Re: [HACKERS] CREATE DATABASE foo OWNER bar

2007-04-17 Thread Bruce Momjian
Tom Lane wrote: > Larry Rosenman <[EMAIL PROTECTED]> writes: > > I guess the issue is that I'd expect public to be owned by the DB Owner > > after > > a CREATE DATABASE foo OWNER bar, > > Why? Do you expect the system catalogs to be owned by the DB owner? > What about other random objects that m

Re: [HACKERS] Unhelpful debug tools on OS X :-(

2007-04-17 Thread Heikki Linnakangas
Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: Tom Lane wrote: Any suggestions how to extract some info out of this? Does OS X have the catchsegv tool? No, but I suddenly remembered about CrashReporter, and sure enough it's catching these crashes: Exception: EXC_BAD_ACCES

Re: [HACKERS] Unhelpful debug tools on OS X :-(

2007-04-17 Thread Tom Lane
I wrote: > Thread 0 Crashed: > 0 postmaster 0x001af4ef smgrextend + 12 (smgr.c:485) > 1 postmaster 0x00029044 end_heap_rewrite + 208 (rewriteheap.c:278) > 2 postmaster 0x000bdc22 cluster_rel + 850 (cluster.c:806) > 3 postmaster 0x000be119 cluster + 160 (cluster.c:220) AFAICS, a crash i

Re: [HACKERS] Unhelpful debug tools on OS X :-(

2007-04-17 Thread Tom Lane
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > But I did notice that we're not fsyncing the newly written relation like > we should. Good point, but doesn't the analogy to copy_relation_data say that we should sync if not rd_istemp? (This is my fault BTW; your original patch kept the data in s

Re: [HACKERS] Unhelpful debug tools on OS X :-(

2007-04-17 Thread Heikki Linnakangas
Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: But I did notice that we're not fsyncing the newly written relation like we should. Good point, but doesn't the analogy to copy_relation_data say that we should sync if not rd_istemp? Right. I don't know why I didn't copy that i

[HACKERS] Can't ri_KeysEqual() consider two nulls as equal?

2007-04-17 Thread Tom Lane
A recent discussion led me to the idea that FK triggers are fired unnecessarily during an UPDATE if the foreign-key column(s) contain any NULLs, because ri_KeysEqual() treats two nulls as unequal, and therefore we conclude the row has changed when it has not. I claim that both ri_KeysEqual() and ri

Re: [HACKERS] RESET command seems pretty disjointed now

2007-04-17 Thread Florian Pflug
Tom Lane wrote: Mark Kirkwood <[EMAIL PROTECTED]> writes: Tom Lane wrote: The current documentation for RESET exhibits a certain lack of, um, intellectual cohesiveness: Synopsis RESET configuration_parameter RESET ALL RESET { PLANS | SESSION | TEMP | TEMPORARY } Maybe DISCARD for the plans

Re: [HACKERS] Hacking on PostgreSQL via GIT

2007-04-17 Thread Martin Langhoff
Florian G. Pflug wrote: >> Initially, I'll post it on http://git.catalyst.net.nz/ and I can run a >> daily import for you - once that's in place you can probably get a repo >> with your work on http://repo.or.cz/ Ok - you can now clone from http://git.catalyst.net.nz/postgresql.git viewable from h

Re: [HACKERS] Hacking on PostgreSQL via GIT

2007-04-17 Thread Martin Langhoff
Florian G. Pflug wrote: > Cool - I'm new to git, so I really appreciate any help that I can get. Great - I am a SoC mentor for 2 other projects (git and moodle) so I've got some time set aside for SoC stuff. You might as well take advantage of it :-) >> For the kind of work you'll be doing (writi

Re: [HACKERS] Can't ri_KeysEqual() consider two nulls as equal?

2007-04-17 Thread Simon Riggs
On Tue, 2007-04-17 at 17:16 -0400, Tom Lane wrote: > A recent discussion led me to the idea that FK triggers are fired > unnecessarily during an UPDATE if the foreign-key column(s) contain > any NULLs, because ri_KeysEqual() treats two nulls as unequal, > and therefore we conclude the row has chang

Re: [HACKERS] where to write small reusable functions ?

2007-04-17 Thread Jim C. Nasby
On Fri, Apr 13, 2007 at 03:02:28PM +0200, Dany DeBontridder wrote: > On 4/13/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: > > > >Dany DeBontridder wrote: > >> I'm working to implement a new feature to pg_dump: the ability to dump > >> objects like function, indexes... > > > >pg_dump already du

Re: [HACKERS] [COMMITTERS] pgsql: Also done for PL/pgSQL: < o Add support for WITH HOLD and

2007-04-17 Thread Tom Lane
[EMAIL PROTECTED] (Bruce Momjian) writes: > Also done for PL/pgSQL: > < o Add support for WITH HOLD and SCROLL cursors > > o -Add support for WITH HOLD and SCROLL cursors WITH HOLD support is not there. regards, tom lane --

Re: [HACKERS] SoC Students/Projects selected

2007-04-17 Thread Jim C. Nasby
On Sun, Apr 15, 2007 at 08:00:23PM -0300, Josh Berkus wrote: > Now, while each of these students has an assigned mentor, that doesn't > mean other people shouldn't help. If you're interested in their work, > please pitch in. > > Note that we'll also be using the pgsql-students mailing list for

Re: [HACKERS] Autovacuum vs statement_timeout

2007-04-17 Thread Jim C. Nasby
On Tue, Apr 17, 2007 at 12:51:51PM -0700, Joshua D. Drake wrote: > Jim C. Nasby wrote: > >On Sun, Apr 01, 2007 at 12:36:01AM +0200, Peter Eisentraut wrote: > >>Tom Lane wrote: > >>>I seem to remember that we'd agreed that autovacuum should ignore any > >>>globally set statement_timeout, on the grou

Re: [HACKERS] utf8 COPY DELIMITER?

2007-04-17 Thread Tatsuo Ishii
> On looking at the code, there's another issue: the CSV escape and quote > characters are assumed to be the same in client and server encodings, > because they're checked for before we do transcoding. This pretty much > restricts them to be ASCII. > > regards, tom lane +1.

Re: [HACKERS] utf8 COPY DELIMITER?

2007-04-17 Thread Tom Lane
Tatsuo Ishii <[EMAIL PROTECTED]> writes: > The message in question should be something like: > "COPY delimiter must be a single ASCII character" If we phrase it like that we should enforce it like that --- ie, reject high-bit-set characters. But I'm a bit hesitant to do so, because it actually d

Re: [HACKERS] Hacking on PostgreSQL via GIT

2007-04-17 Thread Aidan Van Dyk
* Martin Langhoff <[EMAIL PROTECTED]> [070417 17:32]: > > Having a git mirror of the pgsql CVS would be great. > > BTW, I've just check out repo.or.cz, and noticed that there is already a > > git mirror of the pgsql CVS: http://repo.or.cz/w/PostgreSQL.git > > Yes, I've seen it, but I don't know t

Re: [HACKERS] SoC Students/Projects selected

2007-04-17 Thread Josh Berkus
Jim, Will all discussions take place here or in -students? The idea is that discussions about the SoC *program* and "where do I submit ..." questions will go on -students; any questions about actual code will go here or on the appropriate dev list. Probably worth posting about that to -an

Re: [HACKERS] [RFC] PostgreSQL Access Control Extension (PGACE)

2007-04-17 Thread Josh Berkus
Tom, Andrew, KaiGai, "Andrew Dunstan" <[EMAIL PROTECTED]> writes: What's more, we have a SoC project for column level access controls. I don't see the SE stuff as a replacement for that, since it apparently exists outside the standard SQL security model. ... which presumably wouldn't invo

Re: [HACKERS] Can't ri_KeysEqual() consider two nulls as equal?

2007-04-17 Thread Stephan Szabo
On Tue, 17 Apr 2007, Tom Lane wrote: > A recent discussion led me to the idea that FK triggers are fired > unnecessarily during an UPDATE if the foreign-key column(s) contain > any NULLs, because ri_KeysEqual() treats two nulls as unequal, > and therefore we conclude the row has changed when it ha

Re: [HACKERS] [COMMITTERS] pgsql: Also done for PL/pgSQL: < o Add support for WITH HOLD and

2007-04-17 Thread Bruce Momjian
Tom Lane wrote: > [EMAIL PROTECTED] (Bruce Momjian) writes: > > Also done for PL/pgSQL: > > > < o Add support for WITH HOLD and SCROLL cursors > > > o -Add support for WITH HOLD and SCROLL cursors > > WITH HOLD support is not there. Thanks, I was wondering about that. TODO

Re: [HACKERS] Hacking on PostgreSQL via GIT

2007-04-17 Thread Tom Lane
Aidan Van Dyk <[EMAIL PROTECTED]> writes: > I have my CVS->GIT conversion running hourly from the anon-rsync of the > cvsroot. I don't know the specifics of the PostgreSQL rsync/mirror > setup, so I may be pulling it more frequently than it's actually > published, but until I hear from someone tha

Re: [HACKERS] utf8 COPY DELIMITER?

2007-04-17 Thread Bruce Momjian
Tatsuo Ishii wrote: > > On looking at the code, there's another issue: the CSV escape and quote > > characters are assumed to be the same in client and server encodings, > > because they're checked for before we do transcoding. This pretty much > > restricts them to be ASCII. > > > >

Re: [HACKERS] Hacking on PostgreSQL via GIT

2007-04-17 Thread Florian G. Pflug
Martin Langhoff wrote: Aidan Van Dyk wrote: And remember the warning I gave that my conversion is *not* a direct CVS import - I intentionally *unexpand* all Keywords before stuffing them into GIT so that merging and branching can ignore all the Keyword conflicts... My import is unexpanding th

Re: [HACKERS] Autovacuum vs statement_timeout

2007-04-17 Thread Robert Treat
On Tuesday 17 April 2007 18:38, Jim C. Nasby wrote: > On Tue, Apr 17, 2007 at 12:51:51PM -0700, Joshua D. Drake wrote: > > Jim C. Nasby wrote: > > >On Sun, Apr 01, 2007 at 12:36:01AM +0200, Peter Eisentraut wrote: > > >>Tom Lane wrote: > > >>>I seem to remember that we'd agreed that autovacuum shou

Re: [HACKERS] Autovacuum vs statement_timeout

2007-04-17 Thread Tom Lane
Robert Treat <[EMAIL PROTECTED]> writes: > I'm with Joshua on this one. Statement_timeout is often used as a means for > protection from long running statements due to server load and locking and > all of the above commands can certainly fall into that area. If people feel > strongly that the co

Re: [HACKERS] [COMMITTERS] pgsql: Update error message for COPY with a multi-byte delimiter.

2007-04-17 Thread Tom Lane
[EMAIL PROTECTED] (Bruce Momjian) writes: > Update error message for COPY with a multi-byte delimiter. You forgot the CSV strings. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space ma

Re: [HACKERS] Hacking on PostgreSQL via GIT

2007-04-17 Thread Martin Langhoff
Aidan Van Dyk wrote: > I'm an unknown here, I know - I've used PostgreSQL for years, but only > recently started following the development community... And at this I'm probably unknown here as well. Hi everyone ;-) > And remember the warning I gave that my conversion is *not* a direct CVS > impo

Re: [HACKERS] Hacking on PostgreSQL via GIT

2007-04-17 Thread Aidan Van Dyk
* Florian G. Pflug <[EMAIL PROTECTED]> [070417 20:30]: > >So - if you are committed to providing your gateway long term to > >Florian, I'm happy to drop my gateway in favour of yours. > > There seem to be other people than me who are interested in a git > mirror. Maybe we could declare one of tho

Re: [HACKERS] Autovacuum vs statement_timeout

2007-04-17 Thread Joshua D. Drake
Tom Lane wrote: Robert Treat <[EMAIL PROTECTED]> writes: I'm with Joshua on this one. Statement_timeout is often used as a means for protection from long running statements due to server load and locking and all of the above commands can certainly fall into that area. If people feel strongly t

Re: [HACKERS] utf8 COPY DELIMITER?

2007-04-17 Thread Tatsuo Ishii
> Tatsuo Ishii <[EMAIL PROTECTED]> writes: > > The message in question should be something like: > > "COPY delimiter must be a single ASCII character" > > If we phrase it like that we should enforce it like that --- ie, reject > high-bit-set characters. > > But I'm a bit hesitant to do so, becau

Re: [HACKERS] Autovacuum vs statement_timeout

2007-04-17 Thread Alvaro Herrera
Joshua D. Drake wrote: > Tom Lane wrote: > >Robert Treat <[EMAIL PROTECTED]> writes: > >>I'm with Joshua on this one. Statement_timeout is often used as a means > >>for protection from long running statements due to server load and > >>locking and all of the above commands can certainly fall into

[HACKERS] Re: [COMMITTERS] pgsql: Update error message for COPY with a multi-byte delimiter.

2007-04-17 Thread Bruce Momjian
Tom Lane wrote: > [EMAIL PROTECTED] (Bruce Momjian) writes: > > Update error message for COPY with a multi-byte delimiter. > > You forgot the CSV strings. OK, I wasn't clear on those but I am now. I backpatched the doc change to 8.2.X. -- Bruce Momjian <[EMAIL PROTECTED]> http://mo

Re: [HACKERS] Autovacuum vs statement_timeout

2007-04-17 Thread Bruce Momjian
Alvaro Herrera wrote: > I think that is too strong an assumption, which is why I'm planning to > back-patch the change to reset statement_timeout to 0 on autovacuum till > 8.0, as discussed. I think I should also backpatch the change to set > zero_damaged_pages as well (which is not on 8.0 AFAIR).

Re: [HACKERS] Hacking on PostgreSQL via GIT

2007-04-17 Thread Tom Lane
Martin Langhoff <[EMAIL PROTECTED]> writes: > Aidan Van Dyk wrote: >> And remember the warning I gave that my conversion is *not* a direct CVS >> import - I intentionally *unexpand* all Keywords before stuffing them >> into GIT so that merging and branching can ignore all the Keyword >> conflicts..