That does indeed appear to be the case -- the database on the Linux server
has en_CA.UTF-8 collation, while the database on the Windows server has
English_Canada.1252 collation. Thanks!
Doug
On Wed, Apr 27, 2011 at 1:04 PM, Thom Brown wrote:
> On 27 April 2011 20:28, Doug Gorley wrote:
>
>>
On 27 April 2011 20:28, Doug Gorley wrote:
> I'm running the following SQL commands on a new PostgreSQL 9.0 database,
> one on Linux, one on Windows.
>
> create table i (j varchar(4));
> insert into i (j) values ('A'), ('E'), (' select j from i order by j asc;
>
> On the Windows server I get the
I'm running the following SQL commands on a new PostgreSQL 9.0 database, one
on Linux, one on Windows.
create table i (j varchar(4));
insert into i (j) values ('A'), ('E'), ('
On Wed, Oct 14, 2009 at 3:37 PM, Sam Mason wrote:
> On Wed, Oct 14, 2009 at 10:29:56AM -0400, Tom Lane wrote:
> > Paul Hartley writes:
> > > ... I'm unclear
> > > if PostgreSQL treats primary keys differently from unique, non-null
> > > constraints.
> >
> > The *only* thing that the system does
On Wed, Oct 14, 2009 at 10:29:56AM -0400, Tom Lane wrote:
> Paul Hartley writes:
> > ... I'm unclear
> > if PostgreSQL treats primary keys differently from unique, non-null
> > constraints.
>
> The *only* thing that the system does specially with a primary key
> constraint is that a PK creates a
Paul Hartley writes:
> ... I'm unclear
> if PostgreSQL treats primary keys differently from unique, non-null
> constraints.
The *only* thing that the system does specially with a primary key
constraint is that a PK creates a default column target for foreign key
references. For example,
create
there are certain conditions where PK is required, but apart from that it is
pretty much equivalent of unique not null. Obviously index is created, in
order to keep things unique.
the (col1, col2 DESC) type of index is useful, when you have query that uses
it that way. For example, if your query i
Paul Hartley wrote:
> I have a composite primary key for a table, let's call it
> (col1, col2). When this table is created, obviously an
> implicit index is created for this key. I would like the
> sort order of this index to be different for the two columns
> -- if I were to create the index
I have a composite primary key for a table, let's call it (col1, col2).
When this table is created, obviously an implicit index is created for this
key. I would like the sort order of this index to be different for the two
columns -- if I were to create the index myself, I would pass on (col1, co
Try on both servers:
show lc_collate
Unfortunately you have to initdb to set the locale. You can't set it per
database or change it once it's initialized.
Right you are, but I suppose I can do a dump using pg_dumpall overwrite the
cluster
with initdb --locale=en_US and restore it agai
What's the output of the following query on each server?
select name, setting from pg_settings where name ~ '^lc_';
Ahh there's a difference
mydb=# select name, setting from pg_settings where name ~ '^lc_';
name | setting
-+-
lc_collate | en_US
lc_ctype| en_U
Poul Møller Hansen <[EMAIL PROTECTED]> writes:
> I'm wondering why the sort order on these two servers behaves differently.
> The only difference I can see is that one is using a 32.bits Ubuntu and the
> other is on 64bits versions of Ubuntu.
> But why this difference ?
Try on both servers:
sh
On Mon, May 28, 2007 at 07:07:41PM +0200, Poul Møller Hansen wrote:
> I'm wondering why the sort order on these two servers behaves differently.
What's the output of the following query on each server?
select name, setting from pg_settings where name ~ '^lc_';
--
Michael Fuhr
-
I'm wondering why the sort order on these two servers behaves differently.
The only difference I can see is that one is using a 32.bits Ubuntu and
the other is on 64bits versions of Ubuntu.
But why this difference ?
Thanks,
Poul
mydb=# select * from test order by felt1;
felt1
test1
On Mon, Jul 03, 2006 at 12:55:18AM -0400, Tom Lane wrote:
> Fine for you, not so fine for other people with different concerns.
>
> I'm not unsympathetic to your general point, but black-and-white
> arguments won't get far in this discussion. It's all about tradeoffs
> ... it's most definitely no
Tom Lane wrote:
Dragan Matic <[EMAIL PROTECTED]> writes:
I was about to say the same thing. I think that the whole point in
having a portable database system is that the data inside the database
should behave the _same way_ no matter what operating system database is
running on - client sho
Dragan Matic <[EMAIL PROTECTED]> writes:
> I was about to say the same thing. I think that the whole point in
> having a portable database system is that the data inside the database
> should behave the _same way_ no matter what operating system database is
> running on - client shouldn't be awa
On Sun, Jul 02, 2006 at 12:25:43PM -0400, Agent M wrote:
> On Jul 2, 2006, at 6:13 AM, Martijn van Oosterhout wrote:
> >But I don't think anyone is actually considering importing ICU into the
> >postgres source tree, are they?
> Why not?
Because it's a project of similar size to postgres and proba
On 7/2/06, Agent M <[EMAIL PROTECTED]> wrote:
Certain Japanese characters cannot make a reliable round-trip through
Unicode. ICU uses UTF-16 as its store, so the Japanese folks won't be
happy with an ICU-only solution. However, it would still be of great
Could you explain what you mean and wha
On Jul 2, 2006, at 6:13 AM, Martijn van Oosterhout wrote:
But I don't think anyone is actually considering importing ICU into the
postgres source tree, are they?
Why not?
Size - I'm not sure this is relevent since I don't think we want to
incorporate it into postgres itself, just let people us
On Sun, Jul 02, 2006 at 12:13:02PM +0200, Martijn van Oosterhout wrote:
> However, the most important point is that people have said they'll take
> the speed hit if they could get consistant collation.
I can second that.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD
Tomi NA wrote:
On 6/30/06, Martijn van Oosterhout wrote:
On Fri, Jun 30, 2006 at 11:56:19AM +0200, Dragan Matic wrote:
> I have two postgres servers, one on linux (fedora core 5), one on
> windows, both are version 8.1.4.
>
Not beeing able to depend on the engine to consistently collate
stri
On Sat, Jul 01, 2006 at 06:23:07PM -0400, Tom Lane wrote:
> "Tomi NA" <[EMAIL PROTECTED]> writes:
> > Basically, it comes down to three possibilities, doesn't it:
> > 1.) use an existing library
> > 2.) write a pgsql specific implementation
> > 3.) forget about it and tend to other issues
>
> > Pe
"Tomi NA" <[EMAIL PROTECTED]> writes:
> Basically, it comes down to three possibilities, doesn't it:
> 1.) use an existing library
> 2.) write a pgsql specific implementation
> 3.) forget about it and tend to other issues
> Personally, I don't really care if it's 1) or 2): I'm just afraid it's
> g
On 7/1/06, Martijn van Oosterhout wrote:
On Fri, Jun 30, 2006 at 07:29:12PM +0200, Tomi NA wrote:
> If I sound harsh, please excuse me, but I feel like I'm the only one
> who thinks these encoding problems (collation, upper/lowercase,
> multiple languages in a single database) are serious...nobo
On Fri, Jun 30, 2006 at 07:29:12PM +0200, Tomi NA wrote:
> If I sound harsh, please excuse me, but I feel like I'm the only one
> who thinks these encoding problems (collation, upper/lowercase,
> multiple languages in a single database) are serious...nobody seems to
> share the sentiment. Ah well..
On 6/30/06, Martijn van Oosterhout wrote:
On Fri, Jun 30, 2006 at 11:56:19AM +0200, Dragan Matic wrote:
> I have two postgres servers, one on linux (fedora core 5), one on
> windows, both are version 8.1.4.
>
> Both databases are initialized with locale Croatian and win1250 encoding.
>
> running
On Fri, Jun 30, 2006 at 11:56:19AM +0200, Dragan Matic wrote:
> I have two postgres servers, one on linux (fedora core 5), one on
> windows, both are version 8.1.4.
>
> Both databases are initialized with locale Croatian and win1250 encoding.
>
> running pg_controldata on windows returns this
>
I have two postgres servers, one on linux (fedora core 5), one on
windows, both are version 8.1.4.
Both databases are initialized with locale Croatian and win1250 encoding.
running pg_controldata on windows returns this
LC_COLLATE: Croatian_Croatia.1250
LC_CTYPE:Croatian_C
29 matches
Mail list logo
