Re: [PATCHES] Exec statement logging

2005-05-23 Thread Bruce Momjian
Applied. --- Bruce Momjian wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > > > Bruce Momjian writes: > > > > a null for the prepare string. Also, rather than change the API for > > > > pg_parse_query(), I use a global

Re: [PATCHES] [BUGS] BUG #1609: Bug in interval datatype for 64 Bit timestamps

2005-05-23 Thread Bruce Momjian
Tom Lane wrote: > Oliver Siegmar <[EMAIL PROTECTED]> writes: > > On Thursday 21 April 2005 15:57, Tom Lane wrote: > >> If it is only the float case, some imprecision is to be expected. > > > So everything is okay? > > Well, it's not necessarily *wrong*, but maybe we could improve it. > The code c

Re: [PATCHES] plperl tests for currently untested features

2005-05-23 Thread Neil Conway
Andrew Dunstan wrote: The current plperl regression tests do not test the trigger or shared data features. The attached new files remedy that [...] Barring any objections I'll apply this later today. -Neil ---(end of broadcast)--- TIP 1: subscri

Re: [PATCHES] bugfix - contrib/pgbench

2005-05-23 Thread Neil Conway
ITAGAKI Takahiro wrote: But this code seems to be an idiom, "Check the result, but drop commands may be fail". Drop commands might be added to DDLAFTERs some time, so we may leave it. Possibly, but I think checking for something that cannot occur is confusing to the reader (and besides, it is

Re: [PATCHES] character type value is not padded with spaces

2005-05-23 Thread John Hansen
Ahhh... > -Original Message- > From: Tatsuo Ishii [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 24, 2005 9:26 AM > To: John Hansen > Cc: [EMAIL PROTECTED]; pgsql-patches@postgresql.org; > pgsql-hackers@postgresql.org > Subject: Re: [PATCHES] character type value is not padded with spac

Re: [PATCHES] character type value is not padded with spaces

2005-05-23 Thread Tatsuo Ishii
I think you need to test with 5 characters, not 3. -- Tatsuo Ishii > Ahemm,... > > UNICODE DB: > > create table t (a char(10)); > set client_encoding = iso88591; > insert into t VALUES ('æøå'); > > select a, octet_length(a),length(a) from t; > a | octet_length | length > +

Re: [PATCHES] character type value is not padded with spaces

2005-05-23 Thread John Hansen
Ahemm,... UNICODE DB: create table t (a char(10)); set client_encoding = iso88591; insert into t VALUES ('æøå'); select a, octet_length(a),length(a) from t; a | octet_length | length +--+ æøå| 13 | 3 (1 row) This is with 8.0.2.

Re: [PATCHES] character type value is not padded with spaces

2005-05-23 Thread Tatsuo Ishii
Hackers, The problem he found is not only existing in Japanese characters but also in any multibyte encodings including UTF-8. For me the patch looks good and I will commit it to 7.3, 7.4, 8.0 stables and current if there's no objection. -- Tatsuo Ishii > Character type value including multibyte

[PATCHES] plperl tests for currently untested features

2005-05-23 Thread Andrew Dunstan
continuing my quest for better testing ... ;-) The current plperl regression tests do not test the trigger or shared data features. The attached new files remedy that: sql/plperl_trigger.sql sql/plperl_shared.sql expected/plperl_trigger.out expected/plperl_shared.out The corresponding patch

[PATCHES] Remove unnecessary parentheses

2005-05-23 Thread Bruce Momjian
I found many unnecessary parentheses in the datetime/timestamp code. This applied patch removes them. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Chris

Re: [PATCHES] PATCH to allow concurrent VACUUMs to not lock each

2005-05-23 Thread Hannu Krosing
On E, 2005-05-23 at 11:42 -0400, Tom Lane wrote: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > I can't think of any other cases where it could matter, as at least the > > work done inside vacuum_rel() itself seema non-rollbackable. > > VACUUM FULL's tuple-moving is definitely roll-back-able, so

Re: [PATCHES] PATCH to allow concurrent VACUUMs to not lock each

2005-05-23 Thread Tom Lane
Hannu Krosing <[EMAIL PROTECTED]> writes: > I can't think of any other cases where it could matter, as at least the > work done inside vacuum_rel() itself seema non-rollbackable. VACUUM FULL's tuple-moving is definitely roll-back-able, so it might be prudent to only do this for lazy VACUUM. But o

Re: [PATCHES] PATCH to allow concurrent VACUUMs to not lock each

2005-05-23 Thread Hannu Krosing
On E, 2005-05-23 at 10:16 -0400, Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > I'm a little worried about having this set to "true" after a VACUUM is > > executed, and only reset to false when the next transaction is begun: it > > shouldn't affect correctness right now, but it see

Re: [PATCHES] PATCH to allow concurrent VACUUMs to not lock each

2005-05-23 Thread Tom Lane
Neil Conway <[EMAIL PROTECTED]> writes: > I'm a little worried about having this set to "true" after a VACUUM is > executed, and only reset to false when the next transaction is begun: it > shouldn't affect correctness right now, but it seems like asking for > trouble. Resetting the flag to "fal

Re: [PATCHES] PATCH to allow concurrent VACUUMs to not lock each

2005-05-23 Thread Neil Conway
Hannu Krosing wrote: *** src/backend/access/transam/xact.c 28 Apr 2005 21:47:10 - 1.200 --- src/backend/access/transam/xact.c 17 May 2005 22:06:34 - *** *** 1411,1416 --- 1411,1424 AfterTriggerBeginXact(); /* + * mark the transaction as not V

Re: [PATCHES] PATCH to allow concurrent VACUUMs to not lock each other

2005-05-23 Thread Bruce Momjian
Hannu Krosing wrote: > On K, 2005-05-18 at 11:54 +0300, Hannu Krosing wrote: > > The attached patch allows VACUUMS's on small relations to clean up dead > > tuples while VACUUM or ANALYSE is running for a long time on some big > > table. > > > > This is done by adding a "bool inVacuum" to PGPROC a

[PATCHES] psql: \d+ show tablespace of indices

2005-05-23 Thread Qingqing Zhou
Now \d+ is able to show the tablespace details of indices. A sample output is followed: test=# \d+ m Table "public.m" Column | Type | Modifiers | Description +-+---+- i | integer | | j | integer | | Indexes:

Re: [PATCHES] PATCH to allow concurrent VACUUMs to not lock each

2005-05-23 Thread Hannu Krosing
On K, 2005-05-18 at 11:54 +0300, Hannu Krosing wrote: > The attached patch allows VACUUMS's on small relations to clean up dead > tuples while VACUUM or ANALYSE is running for a long time on some big > table. > > This is done by adding a "bool inVacuum" to PGPROC and then making use > of it in Get

Re: [PATCHES] bugfix - contrib/pgbench

2005-05-23 Thread ITAGAKI Takahiro
Neil Conway <[EMAIL PROTECTED]> wrote: > > --- 622,628 > > for (i = 0; i < (sizeof(DDLAFTERs) / sizeof(char *)); i++) > > { > > res = PQexec(con, DDLAFTERs[i]); > > ! if (strncmp(DDLAFTERs[i], "drop", 4) && PQresultStatus(res) != > > PGRES_COMMAND_OK) > >