Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 17. März 2005 19:23 schrieb Tom Lane:
>> It doesn't eliminate the need for initdb, because pg_conversion contains
>> instances of the client-only encoding numbers. I think that clients
>> know the client-only encoding numbers too, so I'
Am Donnerstag, 17. März 2005 19:23 schrieb Tom Lane:
> It doesn't eliminate the need for initdb, because pg_conversion contains
> instances of the client-only encoding numbers. I think that clients
> know the client-only encoding numbers too, so I'm not sure we aren't
> stuck with a compatibility
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > You shouldn't insert encodings in the middle, because those numbers are
> > exposed to clients. We've had troubles with that before. If you add
> > an encoding, append it as the last one (before the client encodings in
> > this
Bruce Momjian writes:
> What should I do with the CVS code now? Why is adding a gap between
> client/server and client-only encodings in pg_wchar.h going to waste
> space?
IIRC there are some tables that are indexed directly by the encoding
number, so leaving holes in the code assignments requir
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> You shouldn't insert encodings in the middle, because those numbers are
> exposed to clients. We've had troubles with that before. If you add
> an encoding, append it as the last one (before the client encodings in
> this case). This would probab
Bruce Momjian wrote:
> Tom Lane wrote:
> > You can't just randomly rearrange the pg_enc enum without forcing
> > an initdb, because the numeric values of the encodings appear in
> > system catalogs (eg pg_conversion).
>
> Oh, those numbers appear in the catalogs? I didn't relealize that.
>
> I wil
Bruce Momjian wrote:
Yes, 8.1 will require a dump/reload for upgrade. I think we decided
that was going to be necessary.
That has aleady happened for 8.1:
date: 2005/02/28 03:45:21; author: neilc; state: Exp; lines: +2 -2
Implement max() and min() aggregates for array types. Pat
Mark Woodward wrote:
> > Tom Lane wrote:
> >> You can't just randomly rearrange the pg_enc enum without forcing an
> >> initdb, because the numeric values of the encodings appear in system
> >> catalogs (eg pg_conversion).
> >
> > Oh, those numbers appear in the catalogs? I didn't relealize that.
> Tom Lane wrote:
>> You can't just randomly rearrange the pg_enc enum without forcing an
>> initdb, because the numeric values of the encodings appear in system
>> catalogs (eg pg_conversion).
>
> Oh, those numbers appear in the catalogs? I didn't relealize that.
>
> I will force an initdb.
>
Doe
Tom Lane wrote:
> You can't just randomly rearrange the pg_enc enum without forcing an
> initdb, because the numeric values of the encodings appear in system
> catalogs (eg pg_conversion).
Oh, those numbers appear in the catalogs? I didn't relealize that.
I will force an initdb.
--
Bruce Mom
10 matches
Mail list logo
