Re: [PATCHES] lastval()

2005-05-11 Thread John Hansen
Tom Lane wrote: Sent: Wednesday, May 11, 2005 3:41 PM To: John Hansen Cc: Neil Conway; Dennis Bjorklund; pgsql-patches@postgresql.org Subject: Re: [PATCHES] lastval() John Hansen [EMAIL PROTECTED] writes: I'm all for it. Even more so if the 'currval(void) called before

[PATCHES] Where is Translation of FARSI FAQ?

2005-05-11 Thread Mahmoud Taghizadeh
Dear list I had submitter farsi translation of postgresql but I can not find its link in website? would you please fix this problem. Regards Yahoo! Mail Stay connected, organized, and protected. Take the tour

Re: [PATCHES] lastval()

2005-05-11 Thread Alvaro Herrera
On Wed, May 11, 2005 at 02:08:16PM +1000, John Hansen wrote: Take for instance this (overly simplified) function used in a program that builds the query strings dynamically: int64 runquery(char *query) { PQexec(query); result = Pqexec(SELECT lastval()); return result; }

[PATCHES] AllocSetReset improvement

2005-05-11 Thread a_ogawa
In SQL that executes aggregation, AllocSetReset is called many times and spend a lot of cycles. This patch saves the cycles spent by AllocSetReset. An idea of the patch is to add a flag to AllocSetContext. This flag shows whether AllocSetReset should work. The effect of

Re: [PATCHES] [BUGS] BUG #1588: pg_autovacuum sleep parameter overflow

2005-05-11 Thread Bruce Momjian
Lionel Bouton wrote: The following bug has been logged online: Bug reference: 1588 Logged by: Lionel Bouton Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.1 Operating system: Linux 2.6, glibc 2.3.4 Description:pg_autovacuum sleep parameter overflow

[PATCHES] plperl and pltcl installcheck targets

2005-05-11 Thread Andrew Dunstan
The attached patch creates installcheck targets for plperl and pltcl (plpython laready has one). This will help in getting buildfarm to test PLs. Is it worth rearranging things for plpython so that it follows the same test layout as the other 2 (i.e. a test subdir with all the test files and a

Re: [PATCHES] [BUGS] BUG #1588: pg_autovacuum sleep parameter overflow

2005-05-11 Thread Andrew Dunstan
Bruce Momjian wrote: */ ! #ifndef WIN32 ! sleep(sleep_secs); /* Unix sleep is seconds */ ! #else ! sleep(sleep_secs * 1000); /* Win32 sleep() is milliseconds */ Shouldn't the be Sleep with a capital S? see

Re: [PATCHES] [BUGS] BUG #1588: pg_autovacuum sleep parameter overflow

2005-05-11 Thread Bruce Momjian
Andrew Dunstan wrote: Bruce Momjian wrote: */ ! #ifndef WIN32 !sleep(sleep_secs); /* Unix sleep is seconds */ ! #else !sleep(sleep_secs * 1000); /* Win32 sleep() is milliseconds */ Shouldn't the be Sleep with

Re: [PATCHES] [BUGS] BUG #1588: pg_autovacuum sleep parameter overflow

2005-05-11 Thread Andrew Dunstan
Bruce Momjian wrote: Andrew Dunstan wrote: Bruce Momjian wrote: */ ! #ifndef WIN32 ! sleep(sleep_secs); /* Unix sleep is seconds */ ! #else ! sleep(sleep_secs * 1000); /* Win32 sleep() is milliseconds */

Re: [PATCHES] [BUGS] BUG #1588: pg_autovacuum sleep parameter overflow

2005-05-11 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes: However, I am now wondering if we should change pg_usleep() to take a double rather than long. This would avoid such problems in the future in other places in our code. I'd leave it alone; there aren't any other places that need long sleeps, and I

Re: [PATCHES] [BUGS] BUG #1588: pg_autovacuum sleep parameter overflow

2005-05-11 Thread Bruce Momjian
Andrew Dunstan wrote: Strange ... as long as you #include windows.h it should be fine, and pg_autovacuum.c already does include it. Anyway, whatever works, I guess. Ah, my test program did not include windows.h. I found it understood sleep() with just the standard Unix includes. I did

Re: [PATCHES] plperl and pltcl installcheck targets

2005-05-11 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: Is it worth rearranging things for plpython so that it follows the same test layout as the other 2 (i.e. a test subdir with all the test files and a script called runtest that does the work)? Especially if we bring in other PLs as has been discussed,

Re: [PATCHES] update some urls

2005-05-11 Thread Bruce Momjian
Patch applied to HEAD and 8.0.X. Thanks. --- Robert Treat wrote: This patch updates a number of urls in a number of files. Most are just poinitng to the TODO list within the main website. -- Robert Treat Build

Re: [PATCHES] Patch that deals with that AtCommit_Portals encounters

2005-05-11 Thread Bruce Momjian
Thomas Hallgren wrote: This patch will ensure that the hash table iteration performed by AtCommit_Portals is restarted when a portal is deleted. This is necessary since the deletion of a portal may cause the deletion of another which on rare occations may cause the iterator to return a

Re: [PATCHES] [BUGS] BUG #1588: pg_autovacuum sleep parameter overflow

2005-05-11 Thread Bruce Momjian
Patch applied and backpatched to 8.0.X. --- Bruce Momjian wrote: Index: contrib/pg_autovacuum/pg_autovacuum.c === RCS file:

Re: [PATCHES] pg_autovacuum micro patch to display database name when

2005-05-11 Thread Bruce Momjian
Patch applied. It will appear in 8.1. Thanks. --- Cosimo Streppone wrote: Here it is, a small tweak to enable display in the log file of database name before table name when VACUUMing or ANALYZing a table. --

Re: [PATCHES] lastval()

2005-05-11 Thread John Hansen
Alvaro Herrera wrote: Sent: Wednesday, May 11, 2005 10:46 PM To: John Hansen Cc: Bruce Momjian; Neil Conway; Dennis Bjorklund; pgsql-patches@postgresql.org Subject: Re: [PATCHES] lastval() On Wed, May 11, 2005 at 02:08:16PM +1000, John Hansen wrote: Take for instance this (overly

Re: [PATCHES] Patch that deals with that AtCommit_Portals encounters

2005-05-11 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes: This patch will ensure that the hash table iteration performed by AtCommit_Portals is restarted when a portal is deleted. I have applied the following patch. I assume it is too risky for backpatch to 8.0.X. I don't think it's appropriate in HEAD

Re: [PATCHES] Patch that deals with that AtCommit_Portals encounters

2005-05-11 Thread Thomas Hallgren
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: This patch will ensure that the hash table iteration performed by AtCommit_Portals is restarted when a portal is deleted. I have applied the following patch. I assume it is too risky for backpatch to 8.0.X. I don't

Re: [HACKERS] [PATCHES] plperl and pltcl installcheck targets

2005-05-11 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Aha. ok. should be fairly trivial. I'm thinking of something like --load-languages=lang1,lang2,lang3 (in case we ever want more than one). Might be a little easier as multiple switches: --load-language=lang1

Re: [HACKERS] [PATCHES] plperl and pltcl installcheck targets

2005-05-11 Thread Andrew Dunstan
Andrew Dunstan wrote: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Aha. ok. should be fairly trivial. I'm thinking of something like --load-languages=lang1,lang2,lang3 (in case we ever want more than one). Might be a little easier as multiple switches:

Re: [PATCHES] lastval()

2005-05-11 Thread Alvaro Herrera
On Thu, May 12, 2005 at 04:58:54AM +1000, John Hansen wrote: Alvaro Herrera wrote: Actually, having it throw an error would be helpful, because then you can find in the application which calls should be replaced by the generic runquery() that has to return nothing versus the one that

Re: [HACKERS] [PATCHES] plperl and pltcl installcheck targets

2005-05-11 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: Ok. Here's a patch for that piece. With this, contrib regression tests don't load plpgsql, but standard core tests do. er this time with a patch attached. Looks good to me, will apply shortly. Are you planning to take a whack at fixing the PL tests

Re: [HACKERS] [PATCHES] plperl and pltcl installcheck targets

2005-05-11 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Ok. Here's a patch for that piece. With this, contrib regression tests don't load plpgsql, but standard core tests do. er this time with a patch attached. Looks good to me, will apply shortly. Are you planning to take a

Re: [PATCHES] AllocSetReset improvement

2005-05-11 Thread Tom Lane
a_ogawa [EMAIL PROTECTED] writes: In SQL that executes aggregation, AllocSetReset is called many times and spend a lot of cycles. This patch saves the cycles spent by AllocSetReset. Hmm. It doesn't seem like this could be a big win overall. It's not possible to save a whole lot of cycles

[PATCHES] CSV consecutive newline bug

2005-05-11 Thread Andrew Dunstan
I have just been alerted to a bug in the 8.0 handling of embedded newlines in CSV data. Basically it barfs on consecutive newlines. The attached patch for 8.0 appears to fix it. The bug isn't present in the HEAD branch, and I'm wondering if we should not backpatch the HEAD multiline patch

Re: [PATCHES] minor contrib/btree_gist cleanup

2005-05-11 Thread Neil Conway
Neil Conway wrote: This patch makes some minor style cleanups to contrib/btree_gist: remove the extern keyword for function definitions, reorganize some PG_GETARG_XXX() usage, and similar. Applied. -Neil ---(end of broadcast)--- TIP 7: don't forget

Re: [PATCHES] CSV consecutive newline bug

2005-05-11 Thread Neil Conway
Andrew Dunstan wrote: I have just been alerted to a bug in the 8.0 handling of embedded newlines in CSV data. Basically it barfs on consecutive newlines. The attached patch for 8.0 appears to fix it. The bug isn't present in the HEAD branch, and I'm wondering if we should not backpatch the HEAD

Re: [PATCHES] CSV consecutive newline bug

2005-05-11 Thread Andrew Dunstan
Neil Conway wrote: Andrew Dunstan wrote: I have just been alerted to a bug in the 8.0 handling of embedded newlines in CSV data. Basically it barfs on consecutive newlines. The attached patch for 8.0 appears to fix it. The bug isn't present in the HEAD branch, and I'm wondering if we should

Re: [PATCHES] Exec statement logging

2005-05-11 Thread Bruce Momjian
Simon Riggs wrote: Following patch is a minor addition to postgres.c that allows the two existing statement logging techniques to work with V3 exec. This then allows statement logging with PostgreSQL 8.0+ for JDBC and other V3 connection types. Good. The rationale of this patch is to add

Re: [HACKERS] [PATCHES] plperl and pltcl installcheck targets

2005-05-11 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: Is that what you had in mind? Not entirely. We should move around the test sql script and the expected result file so that the file structure looks exactly like one of the test-enabled contrib modules. I realize that's a PITA to describe as a patch ---