Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> No, that sounds like it should be sufficient ... but you need to check
> >> the template0 encodings match too, assuming that we make encoding and
> >> locale work the same here.
>
> > OK, are you suggesting checking the pg_database.
Bruce Momjian writes:
> Tom Lane wrote:
>> No, that sounds like it should be sufficient ... but you need to check
>> the template0 encodings match too, assuming that we make encoding and
>> locale work the same here.
> OK, are you suggesting checking the pg_database.encoding for
> template0 for b
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> One problem that just occurred to me is that this solution may not be
> >> adequate for pg_migrator. It will need to check that the new database
> >> has the same "default" settings (where "default" means "those of
> >> template0")
Bruce Momjian writes:
> Tom Lane wrote:
>> One problem that just occurred to me is that this solution may not be
>> adequate for pg_migrator. It will need to check that the new database
>> has the same "default" settings (where "default" means "those of
>> template0") as the old installation did.
Tom Lane wrote:
> One problem that just occurred to me is that this solution may not be
> adequate for pg_migrator. It will need to check that the new database
> has the same "default" settings (where "default" means "those of
> template0") as the old installation did. I think that's probably doa
Alvaro Herrera writes:
> Heikki Linnakangas wrote:
>> If we go with that, we should probably make the notion of a default
>> collation explicit. We could set pg_database.datcollate/datctype column
>> to NULL to mean "use the cluster default".
> I'm not sure how this would work. If I initdb w
Heikki Linnakangas wrote:
> If we go with that, we should probably make the notion of a default
> collation explicit. We could set pg_database.datcollate/datctype column
> to NULL to mean "use the cluster default".
I'm not sure how this would work. If I initdb with a certain
locale/encoding
Peter Eisentraut writes:
> On Friday 08 May 2009 19:09:51 Heikki Linnakangas wrote:
>> How about only outputting the LC_COLLATE/CTYPE options for databases
>> that use a non-default setting?
> That was my latest thinking as well.
Logically we should handle database encoding the same way, no?
I'
On Friday 08 May 2009 19:09:51 Heikki Linnakangas wrote:
> How about only outputting the LC_COLLATE/CTYPE options for databases
> that use a non-default setting? In the common scenarios where you have
> the same collation for the whole cluster it would work just like in
> previous releases. If you
Tom Lane wrote:
Peter Eisentraut writes:
On Thursday 07 May 2009 20:54:37 Alvaro Herrera wrote:
I don't think there's much we can do apart from telling the user not to
move stuff across platforms that do not have equally named locales.
The other part of the problem is that there is no guaran
Peter Eisentraut writes:
> On Thursday 07 May 2009 20:54:37 Alvaro Herrera wrote:
>> I don't think there's much we can do apart from telling the user not to
>> move stuff across platforms that do not have equally named locales.
> The other part of the problem is that there is no guarantee that eq
On Thursday 07 May 2009 20:54:37 Alvaro Herrera wrote:
> I don't think there's much we can do apart from telling the user not to
> move stuff across platforms that do not have equally named locales.
The other part of the problem is that there is no guarantee that equally or
similarly named locale
On May 7, 2009, at 12:32 PM, Tom Lane wrote:
Or we could try to make the user-visible locale names
platform-independent in the first place, a la David's not-silly-at-all
suggestion.
Actually, what I was thinking of was using a platform-independent
locale infrastructure: the inconsistency in
Tom Lane wrote:
> 2. There seem to be some corner cases where creating a table in the new
> database will not create a toast table even though there was one in the
> previous instance. (I'm not 100% convinced that this can happen if we
> create and then drop dropped columns, for instance ... but I
Bernd Helmle writes:
> --On 7. Mai 2009 15:32:01 -0400 Tom Lane wrote:
>> I think the part that goes "en_US" or whatever is actually
>> quite well standardized (except for good ol' Windows, but we could
>> provide a mapping from the Unix-style names to Windows names).
> I like this idea, but i c
--On 7. Mai 2009 15:32:01 -0400 Tom Lane wrote:
I think the part that goes "en_US" or whatever is actually
quite well standardized (except for good ol' Windows, but we could
provide a mapping from the Unix-style names to Windows names).
I like this idea, but i could imagine that this is pre
Magnus Hagander writes:
> Alvaro Herrera wrote:
>> (For text dumps, the only solution would be for the user to edit the
>> dump manually; perhaps provide a pg_dump switch to avoid dumping
>> locale config?).
> We have a pg_dump switch that sets the encoding. Perhaps we could have a
> pg_dump swit
Alvaro Herrera wrote:
> Tom Lane wrote:
>
>> Actually, there's another issue that comes to mind here: since we are
>> relying on platform-dependent locale names, including those in the dump
>> is going to pose a severe problem for porting dumps across platforms
>> (where "different platform" could
Tom Lane wrote:
> Actually, there's another issue that comes to mind here: since we are
> relying on platform-dependent locale names, including those in the dump
> is going to pose a severe problem for porting dumps across platforms
> (where "different platform" could even mean "different libc rel
On May 7, 2009, at 10:18 AM, Tom Lane wrote:
Actually, there's another issue that comes to mind here: since we are
relying on platform-dependent locale names, including those in the
dump
is going to pose a severe problem for porting dumps across platforms
(where "different platform" could eve
I wrote:
> 1. pg_dumpall dumps CREATE DATABASE commands that include the source
> database's encoding, lc_collate, and lc_ctype settings ... but if
> dumping from a pre-8.4 server it just omits the lc_ settings. This
> is flat-out wrong (independently of pg_migrator). The correct behavior
> when
Alvaro Herrera writes:
> Tom Lane wrote:
>> 2. There seem to be some corner cases where creating a table in the new
>> database will not create a toast table even though there was one in the
>> previous instance.
> Hmm, what about toast reloptions? They are not a problem now of course, but
> cou
Tom Lane wrote:
> 2. There seem to be some corner cases where creating a table in the new
> database will not create a toast table even though there was one in the
> previous instance. (I'm not 100% convinced that this can happen if we
> create and then drop dropped columns, for instance ... but
I was just talking to Bruce about his results from testing pg_migrator,
and we realized there are a couple of changes that we need to slip into
the core code before 8.4 goes final.
1. pg_dumpall dumps CREATE DATABASE commands that include the source
database's encoding, lc_collate, and lc_ctype se
24 matches
Mail list logo
