On Wed, Nov 24, 2010 at 3:37 PM, Peter Eisentraut wrote:
> On tor, 2010-10-14 at 22:54 -0400, Robert Haas wrote:
>> It seems you've falsified the header comment in
>> pathkeys_useful_for_merging(), although I guess it's already false
>> because it doesn't seem to have been updated for the NULLS AS
On ons, 2010-09-22 at 19:44 +0900, Itagaki Takahiro wrote:
> * CREATE TABLE (LIKE table_with_collation) doesn't inherit collations.
This was fixed in the CF2010-11 patch.
> * psql \d needs a separator between collate and not null modifiers.
And this as well.
--
Sent via pgsql-hackers mailing
On tor, 2010-10-14 at 22:54 -0400, Robert Haas wrote:
> It seems you've falsified the header comment in
> pathkeys_useful_for_merging(), although I guess it's already false
> because it doesn't seem to have been updated for the NULLS ASC/DESC
> stuff, and the interior comment in right_merge_directi
> I think that that would probably involve a whole lot more notational
> busywork than just replacing typmod with something more complicated.
> However, we're talking about breaking vast amounts of code in either
> case, so maybe making it even vaster isn't a real consideration.
Gods, yes. Pleas
Robert Haas writes:
> On Thu, Oct 21, 2010 at 4:28 PM, Tom Lane wrote:
>> TypeName per se is completely inappropriate for use beyond the first
>> stage of parsing, because it requires catalog lookups to make any sense
>> of. I think the post-parsing representation should still start with a
>> ty
On Thu, Oct 21, 2010 at 4:28 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> We already have TypeName as a structure that contains type and typmod
>> (and collation, in my patch). We could make that a primnode instead of
>> a parsenode, and use it in more places, or we could make a new leaner
Peter Eisentraut writes:
> We already have TypeName as a structure that contains type and typmod
> (and collation, in my patch). We could make that a primnode instead of
> a parsenode, and use it in more places, or we could make a new leaner
> structure that only contains the numeric info.
TypeN
On Thu, Oct 21, 2010 at 2:44 PM, Peter Eisentraut wrote:
> On tor, 2010-10-14 at 22:54 -0400, Robert Haas wrote:
>> and maybe not that bad, but I wonder if there is some preparatory
>> refactoring that could be done to trim it down a bit. I notice, for
>> example, that a lot of places that looked
On tor, 2010-10-14 at 22:54 -0400, Robert Haas wrote:
> and maybe not that bad, but I wonder if there is some preparatory
> refactoring that could be done to trim it down a bit. I notice, for
> example, that a lot of places that looked at first/last> now look at . In
> particular, all the pathke
On Thu, Oct 14, 2010 at 12:53 PM, Peter Eisentraut wrote:
> On ons, 2010-10-13 at 19:15 -0400, Robert Haas wrote:
>> What's the status of this patch?
>
> I would appreciate some more review of the basic architecture.
Wow, what a patch. On the whole, I think this looks pretty good. Of
course,
On ons, 2010-10-13 at 19:15 -0400, Robert Haas wrote:
> What's the status of this patch?
I would appreciate some more review of the basic architecture.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/
On Fri, Sep 24, 2010 at 1:57 AM, Peter Eisentraut wrote:
> On fre, 2010-09-24 at 09:32 +0900, Itagaki Takahiro wrote:
>> On Wed, Sep 22, 2010 at 10:29 PM, Peter Eisentraut wrote:
>> >> We could support it also on MSVC.
>> >> http://msdn.microsoft.com/en-us/library/a7cwbx4t(v=VS.90).aspx --
>> >>
On 09/26/2010 09:37 AM, Greg Stark wrote:
We could have a
encoded_text data type which includes both the encoding and the string
and which any comparison function automatically handles conversion
based on the encoding of the collation requested -- but I wouldn't
want that to be the default text
On Sun, Sep 26, 2010 at 1:15 PM, Pavel Stehule wrote:
> Is there any reason why you prohibit a different encodings per one
> database? Actually people expect from collate per column a possibility
> to store a two or more different encodings per one database.
These are two completely separate prob
Hello Peter
Is there any reason why you prohibit a different encodings per one
database? Actually people expect from collate per column a possibility
to store a two or more different encodings per one database. Without
this possibility - only UTF8 is possible for practical work - and for
other enc
2010/9/24 Peter Eisentraut :
> On tor, 2010-09-23 at 11:55 +0200, Pavel Stehule wrote:
>> > select to_char(current_date,'tmday' collate "cs_CZ.utf8");
>>
>> I am thinking, collates can be used for this purpose too. I see some
>> impacts - this syntax changes a stable function to immutable and it
>>
On tor, 2010-09-23 at 11:55 +0200, Pavel Stehule wrote:
> > select to_char(current_date,'tmday' collate "cs_CZ.utf8");
>
> I am thinking, collates can be used for this purpose too. I see some
> impacts - this syntax changes a stable function to immutable and it
> cannot be simple to solve.
I don'
On fre, 2010-09-24 at 09:32 +0900, Itagaki Takahiro wrote:
> On Wed, Sep 22, 2010 at 10:29 PM, Peter Eisentraut wrote:
> >> We could support it also on MSVC.
> >> http://msdn.microsoft.com/en-us/library/a7cwbx4t(v=VS.90).aspx --
> >> _strcoll_l
> >> http://msdn.microsoft.com/en-us/library/45119yx
On Wed, Sep 22, 2010 at 10:29 PM, Peter Eisentraut wrote:
>> We could support it also on MSVC.
>> http://msdn.microsoft.com/en-us/library/a7cwbx4t(v=VS.90).aspx -- _strcoll_l
>> http://msdn.microsoft.com/en-us/library/45119yx3(v=VS.90).aspx -- _towupper_l
>
> Great.
If we support both glibc and m
2010/9/23 Peter Eisentraut :
> On tor, 2010-09-23 at 10:12 +0200, Pavel Stehule wrote:
>> 1. It's doesn't work with SQL 92 rules for sortby list. I can
>> understand so explicit COLLATE using doesn't work, but the implicit
>> using doesn't work too:
>>
>> CREATE TABLE foo(a text, b text COLLATE "cs
On tor, 2010-09-23 at 17:29 +0900, Itagaki Takahiro wrote:
> On Thu, Sep 23, 2010 at 5:12 PM, Pavel Stehule
> wrote:
> > 5.
> > postgres=# create table xy(a text, b text collate "cs_CZ");
> > ERROR: collation "cs_CZ" for current database encoding "UTF8" does not
> > exist
> > can be there some
On tor, 2010-09-23 at 10:12 +0200, Pavel Stehule wrote:
> 1. It's doesn't work with SQL 92 rules for sortby list. I can
> understand so explicit COLLATE using doesn't work, but the implicit
> using doesn't work too:
>
> CREATE TABLE foo(a text, b text COLLATE "cs_CZ.UTF8")
>
> SELECT * FROM foo O
2010/9/23 Itagaki Takahiro :
> On Thu, Sep 23, 2010 at 5:12 PM, Pavel Stehule
> wrote:
>> 3. postgres=# select to_char(current_date,'tmday') collate "cs_CZ.utf8";
>> to_char
>> ──
>> thursday -- bad result
>> (1 row)
>
> COLLATE means "collation" rather than "locale", no?
ok.
>
>> 5.
On Thu, Sep 23, 2010 at 5:12 PM, Pavel Stehule wrote:
> 3. postgres=# select to_char(current_date,'tmday') collate "cs_CZ.utf8";
> to_char
> ──
> thursday -- bad result
> (1 row)
COLLATE means "collation" rather than "locale", no?
> 5.
> postgres=# create table xy(a text, b text collat
Hello
I am playing with your patch now. I found a few issues:
1. It's doesn't work with SQL 92 rules for sortby list. I can
understand so explicit COLLATE using doesn't work, but the implicit
using doesn't work too:
CREATE TABLE foo(a text, b text COLLATE "cs_CZ.UTF8")
SELECT * FROM foo ORDER B
On ons, 2010-09-22 at 19:44 +0900, Itagaki Takahiro wrote:
> * CREATE TABLE (LIKE table_with_collation) doesn't inherit collations.
> We need to copy collations by default, or add INCLUDING COLLATE option.
OK, should be easy to fix.
> * upper() doesn't work if a column has a collation.
> It s
On Thu, Sep 16, 2010 at 5:46 AM, Peter Eisentraut wrote:
> Following up on my previous patch [0], here is a fairly complete
> implementation of this feature. The general description and
> implementation outline of the previous message still apply. This patch
> contains documentation and regressi
27 matches
Mail list logo
