[HACKERS] strcoll_l an new approach for locale per column

2004-12-22 Thread Mahmoud Taghizadeh
in this list there is some discussion about adding support locale per column. as far as I know the final result was that: because postgresql uses glibc locale functions, and because glibc only handle one locale, postgresql also suppor only one locale at the same time. one solution was that use

Re: [HACKERS] getting 'order by' working with unicode locale? ICU?

2004-12-22 Thread Hannu Krosing
Ühel kenal päeval (laupäev, 18. detsember 2004, 02:41+0100), kirjutas Palle Girgensohn: --On torsdag, december 16, 2004 09.20.50 +0100 Peter Eisentraut [EMAIL PROTECTED] wrote: Palle Girgensohn wrote: Not on FreeBSD, since collation is not implemented in unicode locales. One way would

Re: [HACKERS] Thoughts about updateable views

2004-12-22 Thread Richard Huxton
Jaime Casanova wrote: In a galaxy far, far away Bernd wrote: The context: http://archives.postgresql.org/pgsql-hackers/2004-03/msg00999.php so joined views are even not updateable, too. I don't find the why of this on the specs and the threads about this issue ignore the comment. BEGIN QUOTE In

[HACKERS] Can't Restart ver 8.0b3

2004-12-22 Thread Dave Hartwig
Anyone, I would not describe my situation as desprate (yet), but it is painful, and I am looking for some information and a degree of confidence. I have yet to communicate w/ our sysadmin about backup/restore. We are using version 8.0 beta 3, on Red Hat Linux, to develop a product that we plan

[HACKERS] oldish libpq bug still in RC2

2004-12-22 Thread Hannu Krosing
It seems that this bug is still lurking in libpq: http://search.postgresql.org/pgsql-hackers/2004-09/msg00703.php Is anybody working on it, or should I try something myself, perhaps just replacing the lone recv() with pqsecure_read() ? -- Hannu Krosing [EMAIL PROTECTED]

Re: [HACKERS] Thoughts about updateable views

2004-12-22 Thread Yann Michel
Hi, On Wed, Dec 22, 2004 at 09:41:40AM +, Richard Huxton wrote: UNION etc doesn't necessarily mean you can't update, so long as the underlying table/key can be identified. I think you mean UNION ALL, i.e. the set addition, don't you? Otherwise UNION (wothout ALL) is kind of a aggregation

Re: [HACKERS] Thoughts about updateable views

2004-12-22 Thread Richard Huxton
Yann Michel wrote: Hi, On Wed, Dec 22, 2004 at 09:41:40AM +, Richard Huxton wrote: UNION etc doesn't necessarily mean you can't update, so long as the underlying table/key can be identified. I think you mean UNION ALL, i.e. the set addition, don't you? Otherwise UNION (wothout ALL) is kind

Re: [HACKERS] RC2 and open issues

2004-12-22 Thread Greg Stark
Tom Lane [EMAIL PROTECTED] writes: Maybe we need a hybrid approach: clean a few percent of the LRU end of the ARC list in order to keep backends from blocking on writes, plus run a clock scan to keep checkpoints from having to do much. Well if you just keep note of when the last clock scan

Re: [HACKERS] strcoll_l an new approach for locale per column

2004-12-22 Thread Tom Lane
Mahmoud Taghizadeh [EMAIL PROTECTED] writes: as far as I investigate the glibc code, I found some extention function such as strcol_l and strxfrm_l that let you to pass locale to them. so you dont have to change locale repeatedly. Sorry, but depending on glibc-only functionality is a

Re: [HACKERS] Thoughts about updateable views

2004-12-22 Thread Tom Lane
Richard Huxton dev@archonet.com writes: There are two things (AFAICT) you need to be able to do to update (NOTE - not insert) a view. 1. Identify the underlying table(s) for the updated column(s) 2. Identify (primary) key values for the table(s) being updated. So - I could have a join

Re: [HACKERS] Can't Restart ver 8.0b3

2004-12-22 Thread Tom Lane
Dave Hartwig [EMAIL PROTECTED] writes: LOG: next transaction ID: 884736; next OID: 306834 PANIC: could not access status of transaction 884736 DETAIL: could not read from file /usr/local/pgsql8b3/data/pg_clog/ at offset 221184: Success LOG: startup process (PID 17774) was terminated

Re: [HACKERS] oldish libpq bug still in RC2

2004-12-22 Thread Tom Lane
Hannu Krosing [EMAIL PROTECTED] writes: It seems that this bug is still lurking in libpq: http://search.postgresql.org/pgsql-hackers/2004-09/msg00703.php Is anybody working on it, or should I try something myself, perhaps just replacing the lone recv() with pqsecure_read() ? Go for it. The

Re: [HACKERS] Thoughts about updateable views

2004-12-22 Thread Bernd Helmle
--On Mittwoch, Dezember 22, 2004 11:25:42 -0500 Tom Lane [EMAIL PROTECTED] wrote: Richard Huxton dev@archonet.com writes: There are two things (AFAICT) you need to be able to do to update (NOTE - not insert) a view. 1. Identify the underlying table(s) for the updated column(s) 2. Identify

Re: [HACKERS] Thoughts about updateable views

2004-12-22 Thread Tom Lane
Richard Huxton dev@archonet.com writes: Yann Michel wrote: I think you mean UNION ALL, i.e. the set addition, don't you? Not if you can identify the underlying table(s) and key(s). If the UNION hides that information, then you are correct. If a unique key of the underlying table is included

Re: [HACKERS] Thoughts about updateable views

2004-12-22 Thread Richard Huxton
Tom Lane wrote: Richard Huxton dev@archonet.com writes: There are two things (AFAICT) you need to be able to do to update (NOTE - not insert) a view. 1. Identify the underlying table(s) for the updated column(s) 2. Identify (primary) key values for the table(s) being updated. So - I could have

Re: [HACKERS] Thoughts about updateable views

2004-12-22 Thread Tom Lane
Richard Huxton dev@archonet.com writes: Tom Lane wrote: No; you'd also have to have some guarantee that a given underlying table row gives rise to at most one join row. If the same table row gives rise to multiple join rows, then a request specifying an UPDATE of just one of those join rows

Re: [HACKERS] Thoughts about updateable views

2004-12-22 Thread Richard Huxton
Tom Lane wrote: Richard Huxton dev@archonet.com writes: Yann Michel wrote: I think you mean UNION ALL, i.e. the set addition, don't you? Not if you can identify the underlying table(s) and key(s). If the UNION hides that information, then you are correct. If a unique key of the underlying table

Re: [HACKERS] Thoughts about updateable views

2004-12-22 Thread Richard Huxton
Tom Lane wrote: Richard Huxton dev@archonet.com writes: Tom Lane wrote: No; you'd also have to have some guarantee that a given underlying table row gives rise to at most one join row. If the same table row gives rise to multiple join rows, then a request specifying an UPDATE of just one of those

Re: [HACKERS] Can't Restart ver 8.0b3

2004-12-22 Thread Dave Hartwig
Bingo! Thanks Tom. -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 22, 2004 11:33 AM To: Dave Hartwig Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Can't Restart ver 8.0b3 Dave Hartwig [EMAIL PROTECTED] writes: LOG: next transaction

Re: [HACKERS] Can't Restart ver 8.0b3

2004-12-22 Thread Tom Lane
I wrote: Dave Hartwig [EMAIL PROTECTED] writes: LOG: next transaction ID: 884736; next OID: 306834 PANIC: could not access status of transaction 884736 DETAIL: could not read from file /usr/local/pgsql8b3/data/pg_clog/ at offset 221184: Success LOG: startup process (PID 17774) was

Re: [HACKERS] Bgwriter behavior

2004-12-22 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: So what are we doing for 8.0? Well, it looks like RC2 has already crashed and burned --- I can't imagine that Marc will let us release without an RC3 given what was committed today, never mind the btree bug that Mark Wong seems

[HACKERS] Regression (semi)fix for netbsd-mac68k

2004-12-22 Thread Rémi Zara
Hi, One of the regression failure on NetBSD mac68k is float8 (see http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=ospreybr=HEAD). The failure is due to the fact the strtod does not underflow for +-10e-400. I see in src/test/regress/resultmap that NetBSD ix86 does not overflow either, and

Re: [HACKERS] Regression (semi)fix for netbsd-mac68k

2004-12-22 Thread Tom Lane
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes: --- src/test/regress/resultmap.orig 2004-10-04 16:42:47.0=20 +0200 +++ src/test/regress/resultmap 2004-12-22 23:27:51.0 +0100 @@ -3,6 +3,7 @@ float8/i.86-.*-freebsd[234]=float8-small-is-zero

Re: [HACKERS] Regression (semi)fix for netbsd-mac68k

2004-12-22 Thread Rémi Zara
Le 23 déc. 04, à 00:26, Tom Lane a écrit : =?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes: --- src/test/regress/resultmap.orig 2004-10-04 16:42:47.0=20 +0200 +++ src/test/regress/resultmap 2004-12-22 23:27:51.0 +0100 @@ -3,6 +3,7 @@

Re: [HACKERS] RC2 and open issues

2004-12-22 Thread Simon Riggs
On Tue, 2004-12-21 at 15:26, Tom Lane wrote: Richard Huxton dev@archonet.com writes: However, one thing you can say is that if block B hasn't been written to since you last checked, then any blocks older than that haven't been written to either. [ itch... ] Can you? I don't recall

Re: [HACKERS] Regression (semi)fix for netbsd-mac68k

2004-12-22 Thread Tom Lane
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes: Le 23 d=E9c. 04, =E0 00:26, Tom Lane a =E9crit : Looks reasonable to me --- why do you call it only a semi fix Because strtod really should underflow, so there seems to be a bug in NetBSD's strtod. So this is just accepting the bug, not

Re: [HACKERS] Regression (semi)fix for netbsd-mac68k

2004-12-22 Thread Rémi Zara
Le 23 déc. 04, à 04:52, Tom Lane a écrit : =?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes: Le 23 d=E9c. 04, =E0 00:26, Tom Lane a =E9crit : Looks reasonable to me --- why do you call it only a semi fix Because strtod really should underflow, so there seems to be a bug in NetBSD's strtod.