On Thu, Jun 3, 2010 at 3:43 AM, Peter Eisentraut wrote:
> On ons, 2010-06-02 at 16:56 -0400, Robert Haas wrote:
>> But in the end the only purpose of setting it on a column is to set
>> which one will be used for operations on that column. And the user
>> might still override it for a particular
On tor, 2010-06-03 at 07:30 -0500, David Christensen wrote:
> How does collation relate to per-table/column encodings?
There is some connection between collations and character sets or
encodings, because a collation is tied to one of those, just as a
necessity of implementation (depending on imple
On Jun 3, 2010, at 2:43 AM, Peter Eisentraut wrote:
> On ons, 2010-06-02 at 16:56 -0400, Robert Haas wrote:
>> But in the end the only purpose of setting it on a column is to set
>> which one will be used for operations on that column. And the user
>> might still override it for a particular que
On ons, 2010-06-02 at 16:56 -0400, Robert Haas wrote:
> But in the end the only purpose of setting it on a column is to set
> which one will be used for operations on that column. And the user
> might still override it for a particular query.
Of course. I'm just saying that it *can* be useful to
On Wed, Jun 2, 2010 at 3:46 PM, Peter Eisentraut wrote:
> On fre, 2010-05-28 at 20:59 +0300, Peter Eisentraut wrote:
>> The feature I'm thinking of is what
>> people might call "per-column locale", and the SQL standard defines
>> that. It would look like this:
>>
>> CREATE TABLE test (
>> a v
On fre, 2010-05-28 at 20:59 +0300, Peter Eisentraut wrote:
> The feature I'm thinking of is what
> people might call "per-column locale", and the SQL standard defines
> that. It would look like this:
>
> CREATE TABLE test (
> a varchar COLLATE de,
> b varchar COLLATE fr
> );
>
> SELECT *
On lör, 2010-05-29 at 00:18 +0300, Heikki Linnakangas wrote:
> What does the spec have to say about the ctype used for upper() et al
> BTW?
It doesn't make any provisions for locale dependencies for that.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
On Fri, May 28, 2010 at 10:32:34PM +0300, Peter Eisentraut wrote:
> On fre, 2010-05-28 at 14:48 -0400, Tom Lane wrote:
> > > SELECT * FROM test WHERE a COLLATE en > 'baz' ORDER BY b COLLATE sv;
> >
> > That seems fairly bizarre. What does this mean:
> >
> > WHERE a COLLATE en > b COLLATE de
On 28/05/10 23:15, Robert Haas wrote:
On Fri, May 28, 2010 at 3:20 PM, Peter Eisentraut wrote:
On fre, 2010-05-28 at 15:03 -0400, Robert Haas wrote:
I think we need to think of the comparison operators as ternary, and
the COLLATE syntax applied to columns or present in queries as various
ways
2010/5/28 alvherre :
> Excerpts from Peter Eisentraut's message of vie may 28 12:27:52 -0400 2010:
>
>> Option 2, invent some new mechanism that accompanies a datum or a type
>> whereever it goes. Kind of like typmod, but not really. Then the
>> collation information would presumably be made avai
On Fri, May 28, 2010 at 3:20 PM, Peter Eisentraut wrote:
> On fre, 2010-05-28 at 15:03 -0400, Robert Haas wrote:
>> I think we need to think of the comparison operators as ternary, and
>> the COLLATE syntax applied to columns or present in queries as various
>> ways of setting defaults or explicit
Hi,
Peter Eisentraut writes:
> On fre, 2010-05-28 at 20:22 +0300, Heikki Linnakangas wrote:
>> USING syntax). The behavior is exactly what we want, it's
>> just completely inpractical, so we need something to do the same in a
>> less cumbersome way.
For an example, here is something I did to
On fre, 2010-05-28 at 14:48 -0400, Tom Lane wrote:
> > SELECT * FROM test WHERE a COLLATE en > 'baz' ORDER BY b COLLATE sv;
>
> That seems fairly bizarre. What does this mean:
>
> WHERE a COLLATE en > b COLLATE de
>
> ? If it's an error, why is this not an error
>
> WHERE a COLLAT
On fre, 2010-05-28 at 15:03 -0400, Robert Haas wrote:
> I think we need to think of the comparison operators as ternary, and
> the COLLATE syntax applied to columns or present in queries as various
> ways of setting defaults or explicit overrides for what the third
> argument will end up being.
Ho
On Fri, May 28, 2010 at 2:48 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> So while it's true that the collation is used by the operations (> and
>> ORDER BY), the information which collation to use comes with the data
>> values. It's basically saying, a is in language "de", so sort it like
Peter Eisentraut writes:
> So while it's true that the collation is used by the operations (> and
> ORDER BY), the information which collation to use comes with the data
> values. It's basically saying, a is in language "de", so sort it like
> that unless told otherwise. There is also an overrid
On fre, 2010-05-28 at 20:22 +0300, Heikki Linnakangas wrote:
> It's also fundamentally wrong, collation is not a property of a datum
> but of the operation.
> One way to approach this is to realize that it's already possible to
> use
> multiple collations in a database. You just have to define s
On 28/05/10 19:27, Peter Eisentraut wrote:
I have been thinking about this collation support business a bit.
Ignoring for the moment where we would get the actual collation routines
from, I wonder how we are going to pass this information around in the
system. Someone declares a collation on a c
Excerpts from Peter Eisentraut's message of vie may 28 12:27:52 -0400 2010:
> Option 2, invent some new mechanism that accompanies a datum or a type
> whereever it goes. Kind of like typmod, but not really. Then the
> collation information would presumably be made available to functions
> throug
I have been thinking about this collation support business a bit.
Ignoring for the moment where we would get the actual collation routines
from, I wonder how we are going to pass this information around in the
system. Someone declares a collation on a column in a table, and
somehow this informatio
20 matches
Mail list logo
