"Marc Mamin" <[EMAIL PROTECTED]> writes:
> Description:ALTER TYPE change the underlying index
> tablespace to default
Good catch, will fix.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading throug
OK, I spent some time analyzing this problem, and I think there's a
fairly simple way to avoid a libpq ABI break between 8.2 and 8.3.
Although we removed PG_JOHAB as a backend encoding, we added
PG_EUC_JIS_2004. Therefore, if we rearrange things to give
PG_EUC_JIS_2004 the old number of PG_JOHAB,
Martin Pitt <[EMAIL PROTECTED]> writes:
> Sounds convincing. The hard part is that this then also a bug in 8.2's
> initdb, which cannot be changed,
Why not? Also, is there really a bug in 8.2 or before? chklocale.c
is new in 8.3.
regards, tom lane
--
Hi,
Tom Lane [2007-10-12 13:23 -0400]:
> I'm becoming more and more convinced that this is initdb's bug not
> libpq's. The problem stems from initdb using libpq's functions and
> assuming that its numbers match up with pg_wchar.h. But note that
> pg_wchar.h is not exported by libpq.
Sounds conv
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> But OTOH, I feel we should just stop exporting them now; I don't think
> there's a legitimate use case for a client application to use them.
Actually, that doesn't seem workable as a solution to our immediate
problem: we surely can't remove export
Heikki Linnakangas wrote:
> Note that we've also added PG_EUC_JIS_2004 and PG_SJIS (client-only) to
> the enumeration. That means that all the previous client-only encodings
> have been shifted by two.
On closer look, PG_SJIS is not new, PG_SHIFT_JIS-2004 is. But that was
added to the end, so the
Hi,
Tom Lane [2007-10-12 12:02 -0400]:
> Does anything other than initdb get weird?
It's hard to tell, my test suite concentrates on hammering initdbs
with various locales, encodings, getting a chain of 7.4->8.{0,1,2,3}
upgrades and testing the conversion of postgresql.conf arguments, etc.
I do n
"ITAGAKI Takahiro" <[EMAIL PROTECTED]> writes:
> WAL Writer requests unnecessary checkpoints with CHECKPOINT_CAUSE_XLOG.
> RedoRecPtr, declared in xlog.c, is initialized at StartupXLOG() but never
> updated in WAL Writer because it never calls XLogInsert(). It judges excess
> of segments wrongly.
Tom Lane wrote:
> Martin Pitt <[EMAIL PROTECTED]> writes:
>> However, if I use 8.2 programs with the 8.3 library, things start to
>> become weird:
>
>> $ # kill postgres instance
>> $ rm -rf /tmp/x; LC_ALL=3Den_US.UTF-8 /usr/lib/postgresql/8.2/bin/initdb =
>> --encoding UTF8 -D /tmp/x
>
> Doe
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Perhaps we should leave a gap where JOHAB used to be and add it at the end.
> Otherwise we may have to do a soname exercise.
The question to me is whether the encoding numbers used by libpq
should be considered anything other than black-box numbers.
Am Freitag, 12. Oktober 2007 schrieb Tom Lane:
> Sorry, you don't get to put JOHAB back into the portion of the list that
> is backend-legal encodings.
>
> It's a bit nasty that this enum is exposed as part of the ABI, but I'm
> afraid we may be stuck with that decision.
Perhaps we should leave a
Hi,
Tom Lane [2007-10-12 11:50 -0400]:
> Martin Pitt <[EMAIL PROTECTED]> writes:
> > Ah, got it. The ordering in pg_enc2name_tbl[] changed, which makes the
> > indices jump around.
>
> Sorry, you don't get to put JOHAB back into the portion of the list that
> is backend-legal encodings.
Ah, the
Martin Pitt <[EMAIL PROTECTED]> writes:
> However, if I use 8.2 programs with the 8.3 library, things start to
> become weird:
> $ # kill postgres instance
> $ rm -rf /tmp/x; LC_ALL=3Den_US.UTF-8 /usr/lib/postgresql/8.2/bin/initdb =
> --encoding UTF8 -D /tmp/x
Does anything other than initdb
Martin Pitt <[EMAIL PROTECTED]> writes:
> Ah, got it. The ordering in pg_enc2name_tbl[] changed, which makes the
> indices jump around.
Sorry, you don't get to put JOHAB back into the portion of the list that
is backend-legal encodings.
It's a bit nasty that this enum is exposed as part of the AB
Hi,
Martin Pitt [2007-10-12 16:33 +0200]:
> I'm currently hunting down the last postgresql-common test case
> failure that I see with 8.3beta1. It seems the 8.3 version of libpq
> changes some internal encoding lists?
Ah, got it. The ordering in pg_enc2name_tbl[] changed, which makes the
indices
The following bug has been logged online:
Bug reference: 3674
Logged by: ITAGAKI Takahiro
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3beta1
Operating system: independent
Description:Unnecessary checkpoints by WAL Writer
Details:
WAL Writer requests unnec
Hi PostgreSQL developers,
I'm currently hunting down the last postgresql-common test case
failure that I see with 8.3beta1. It seems the 8.3 version of libpq
changes some internal encoding lists?
If I use the 8.2 programs with the 8.2 library, all is well:
$ LC_ALL=en_US.UTF-8 /usr/lib/postgre
Neil Conway <[EMAIL PROTECTED]> writes:
> I wouldn't call this behavior buggy, but I found it somewhat surprising.
> expression_tree_walker() assumes that the walker has already been
> invoked on the current node (the node that a given recursive call of
> expression_tree_walker() has been invoked o
Timur Luchkin wrote:
> I have stored procedure in "plperlu" language. After the call to it Im
> getting "could not open relation ... No such file or directory" on any next
> operation in psql (the procedure itself works fine). If I'll close the
> console and reopen it again, then everything works f
The following bug has been logged online:
Bug reference: 3673
Logged by: Timur Luchkin
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Fedora Core 5 / Red Hat Ent. Linux AS 3
Description:Untrusted perl language: ERROR: could not open relat
The following bug has been logged online:
Bug reference: 3672
Logged by: Marc Mamin
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Linux
Description:ALTER TYPE change the underlying index
tablespace to default
Details:
steps to repeat:
On Fri, Oct 12, 2007 at 05:23:30PM +0900, KODAMA, Toshihito wrote:
> Hello everyone.
> Sorry,I'm not good at English.
>
> But Postgres8.2(Win) installer error ocurred.
>
> Installing, when creating initdb process says error as follows,
> "WS2 32.dll can't find. Fatal error"
>
> See Program Files
Hello everyone.
Sorry,I'm not good at English.
But Postgres8.2(Win) installer error ocurred.
Installing, when creating initdb process says error as follows,
"WS2 32.dll can't find. Fatal error"
See Program Files/PostgreSQL/8.2/tmp
But,that file is empty.
Regards,
Thanks.
--
Toshihito Kodama
23 matches
Mail list logo
