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
Ü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
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
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
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]
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
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
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
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
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
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
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
--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
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
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
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
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
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
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
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
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
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
=?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
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 @@
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
=?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
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.
27 matches
Mail list logo