On tis, 2011-02-08 at 22:17 +, Thom Brown wrote:
> postgres=# create table meow (id serial, stuff text collate "de_XX");
> NOTICE: CREATE TABLE will create implicit sequence "meow_id_seq" for
> serial column "meow.id"
> ERROR: collation "de_XX" for current database encoding "UTF8" does not ex
On 8 February 2011 21:08, Peter Eisentraut wrote:
> On tor, 2011-02-03 at 18:36 -0500, Noah Misch wrote:
>> Looks good and tests well. I've attached the same benchmark script
>> with updated timings, and I've marked the patch Ready for Committer.
>
> Committed. Thanks everyone.
Awesome work Pet
On tor, 2011-02-03 at 18:36 -0500, Noah Misch wrote:
> Looks good and tests well. I've attached the same benchmark script
> with updated timings, and I've marked the patch Ready for Committer.
Committed. Thanks everyone.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Noah Misch wrote:
> On Thu, Feb 03, 2011 at 05:53:28PM +0200, Peter Eisentraut wrote:
> > On tor, 2011-02-03 at 00:10 -0500, Noah Misch wrote:
> > > > This is good stuff. I'll send you a new patch in a day or three for
> > > > perhaps another round of performance tests. Some of the other
> > > is
On Thu, Feb 03, 2011 at 05:53:28PM +0200, Peter Eisentraut wrote:
> On tor, 2011-02-03 at 00:10 -0500, Noah Misch wrote:
> > > This is good stuff. I'll send you a new patch in a day or three for
> > > perhaps another round of performance tests. Some of the other
> > issues
> > > above can perhaps
On Wed, Feb 02, 2011 at 11:20:44PM +0200, Peter Eisentraut wrote:
> On l??r, 2011-01-29 at 02:52 -0500, Noah Misch wrote:
> > The new documentation is helpful. It would be useful to document the
> > implications of marking your user-defined type COLLATABLE. As best I can
> > tell,
> > you should
On lör, 2011-01-29 at 02:52 -0500, Noah Misch wrote:
> I'm reviewing this patch as part of CommitFest 2011-01.
Thank you very much for this thorough review.
> This no longer applies cleanly against git master, so I've done my testing
> against 52713d0.
I will send an updated patch soon, when I
On Sat, Jan 29, 2011 at 2:52 AM, Noah Misch wrote:
> The 13% slowdown with the feature unused seems worrisome
Very worrisome. This is a frequently-requested feature, but this
seems like a potential show-stopper.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
Hi Peter,
I'm reviewing this patch as part of CommitFest 2011-01.
On Fri, Jan 14, 2011 at 11:41:46PM +0200, Peter Eisentraut wrote:
> I've been going over this patch with a fine-tooth comb for the last two
> weeks, fixed some small bugs, added comments, made initdb a little
> friendlier, but no s
On Wed, Jan 26, 2011 at 12:35:07AM +0200, Peter Eisentraut wrote:
> On tis, 2011-01-25 at 10:14 +0900, Itagaki Takahiro wrote:
> > and I have an almost empty pg_collation catalog with it:
> >
> > =# SELECT * FROM pg_collation;
> > collname | collnamespace | collencoding | collcollate | collctype
On tis, 2011-01-25 at 10:14 +0900, Itagaki Takahiro wrote:
> On Sat, Jan 15, 2011 at 06:41, Peter Eisentraut wrote:
> > I've been going over this patch with a fine-tooth comb for the last two
> > weeks, fixed some small bugs, added comments, made initdb a little
> > friendlier, but no substantial
On Sat, Jan 15, 2011 at 06:41, Peter Eisentraut wrote:
> I've been going over this patch with a fine-tooth comb for the last two
> weeks, fixed some small bugs, added comments, made initdb a little
> friendlier, but no substantial changes.
What can I do to test the patch?
No regression tests are
Em 14-01-2011 20:47, Robert Haas escreveu:
On Fri, Jan 14, 2011 at 4:41 PM, Peter Eisentraut wrote:
I've been going over this patch with a fine-tooth comb for the last two
weeks, fixed some small bugs, added comments, made initdb a little
friendlier, but no substantial changes.
I'm going to st
On Fri, Jan 14, 2011 at 4:41 PM, Peter Eisentraut wrote:
> I've been going over this patch with a fine-tooth comb for the last two
> weeks, fixed some small bugs, added comments, made initdb a little
> friendlier, but no substantial changes.
>
> I'm going to start working on SQL-level CREATE/DROP/
Itagaki Takahiro wrote:
We might need "previous reviewers" and "active reviewers" in commit-fest
app. Or, should non-active reviewers delete their names?
This is only really an issue with patches that get moved from one CF to
the next, which doesn't happen that often. Patches that are mark
On Thu, Dec 16, 2010 at 19:37, Greg Smith wrote:
> I just updated the CF app to track Peter's latest update, which remains
> untested by anyone else for whether it fixes all the issues brought up. It
> would be nice to get a re-review to confirm things are still working in
> advance of CF 2011-01
Robert Haas wrote:
I don't really have a position on whether or not this patch is ready
to commit... but I do think that this is the sort of patch that is
very likely to have some bugs almost no matter when we commit it
I just updated the CF app to track Peter's latest update, which remains
un
On Sun, Dec 12, 2010 at 5:15 PM, Peter Eisentraut wrote:
> On lör, 2010-12-04 at 18:04 +0200, Peter Eisentraut wrote:
>> Here is an updated patch to address the issues discussed during this
>> commitfest.
>
> And another one, that fixes the problems pointed out since.
I don't really have a positi
On mån, 2010-12-06 at 21:26 +0200, Peter Eisentraut wrote:
>
> > * contrib/citext raises an encoding error when COLLATE is specified
> > even if it is the collation as same as the database default.
> > We might need some special treatment for C locale.
> > =# SHOW lc_collate; ==> C
> > =# SELECT
On tis, 2010-12-07 at 11:46 +0900, Itagaki Takahiro wrote:
> On Sun, Dec 5, 2010 at 01:04, Peter Eisentraut wrote:
> > Here is an updated patch to address the issues discussed during this
> > commitfest.
>
> I found another issue in the patch; ILIKE in WHERE clause doesn't work.
> It was surprisi
On Sun, Dec 5, 2010 at 01:04, Peter Eisentraut wrote:
> Here is an updated patch to address the issues discussed during this
> commitfest.
I found another issue in the patch; ILIKE in WHERE clause doesn't work.
It was surprising because LIKE in WHERE clause and ILIKE in SELECT list
works expected
Please
It would be very important to us that the Brazilian LIKE collate worked
with, and possible case-insensitive and accent-insensitive
Tank's
Alexandre Riveira
Brazil
Peter Eisentraut escreveu:
On mån, 2010-12-06 at 10:01 -0800, David E. Wheeler wrote:
I've been wondering if this pa
On Dec 6, 2010, at 11:29 AM, Peter Eisentraut wrote:
> This has been touch upon several times during the discussions on past
> patches.
>
> Essentially, the current patch only arranges that you can specify a sort
> order for data. The system always breaks ties using a binary
> comparison. This
On mån, 2010-12-06 at 10:01 -0800, David E. Wheeler wrote:
> I've been wondering if this patch will support case-insensitve
> collations. If so, then citext should probably be revised to use one.
This has been touch upon several times during the discussions on past
patches.
Essentially, the curre
On mån, 2010-12-06 at 21:06 +0900, Itagaki Takahiro wrote:
> On Sun, Dec 5, 2010 at 01:04, Peter Eisentraut wrote:
> > Here is an updated patch to address the issues discussed during this
> > commitfest.
>
> Here are comments and questions after I tested the latest patch:
>
> Issues
>
2010/12/6 David E. Wheeler :
> On Dec 6, 2010, at 4:06 AM, Itagaki Takahiro wrote:
>
>> * contrib/citext raises an encoding error when COLLATE is specified
>> even if it is the collation as same as the database default.
>> We might need some special treatment for C locale.
>
> I've been wondering i
On Dec 6, 2010, at 4:06 AM, Itagaki Takahiro wrote:
> * contrib/citext raises an encoding error when COLLATE is specified
> even if it is the collation as same as the database default.
> We might need some special treatment for C locale.
I've been wondering if this patch will support case-insensi
On Sun, Dec 5, 2010 at 01:04, Peter Eisentraut wrote:
> Here is an updated patch to address the issues discussed during this
> commitfest.
Here are comments and questions after I tested the latest patch:
Issues
* initdb itself seems to be succeeded, but it says "could not determine
enc
On ons, 2010-11-24 at 22:22 +0200, Peter Eisentraut wrote:
> On mån, 2010-11-22 at 11:58 +0900, Itagaki Takahiro wrote:
> > * Did you see any performance regression by collation?
> > I found a bug in lc_collate_is_c(); result >= 0 should be
> > checked before any other checks. SearchSysCache1() her
On tor, 2010-11-18 at 21:37 +0200, Heikki Linnakangas wrote:
> On 15.11.2010 21:42, Peter Eisentraut wrote:
> > On mån, 2010-11-15 at 11:34 +0100, Pavel Stehule wrote:
> >> I am checking a patch. I found a problem with initdb
> >
> > Ah, late night brain farts, it appears. Here is a corrected vers
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
On mån, 2010-11-22 at 11:58 +0900, Itagaki Takahiro wrote:
> * Did you see any performance regression by collation?
> I found a bug in lc_collate_is_c(); result >= 0 should be
> checked before any other checks. SearchSysCache1() here
> would be a performance regression.
That code turned out to be
On mån, 2010-11-22 at 11:58 +0900, Itagaki Takahiro wrote:
> * COLLATE information must be explicitly passed by caller in the patch,
> but we might forgot the handover when we write new codes. Is it possible
> to pass it automatically, say using a global variable? If we could do so,
> existing exte
On tor, 2010-11-18 at 21:37 +0200, Heikki Linnakangas wrote:
> Have you done any performance testing? Functions like text_cmp can be
> a hotspot in sorting, so any extra overhead there might be show up in
> tests.
Without having optimized it very much yet, the performance for a 1GB
ORDER BY is
*
On Tue, Nov 16, 2010 at 04:42, Peter Eisentraut wrote:
> On mån, 2010-11-15 at 11:34 +0100, Pavel Stehule wrote:
>> I am checking a patch. I found a problem with initdb
> Ah, late night brain farts, it appears. Here is a corrected version.
This version cannot be applied cleanly any more. Please
On 15.11.2010 21:42, Peter Eisentraut wrote:
On mån, 2010-11-15 at 11:34 +0100, Pavel Stehule wrote:
I am checking a patch. I found a problem with initdb
Ah, late night brain farts, it appears. Here is a corrected version.
Some random comments:
In syntax.sgml:
+The COLLATE clause ove
2010/11/16 Tom Lane :
> Martijn van Oosterhout writes:
>> On Tue, Nov 16, 2010 at 10:32:01PM +0200, Peter Eisentraut wrote:
>>> On tis, 2010-11-16 at 21:05 +0100, marcin mank wrote:
It would be nice if we could have some mapping of locale names bult
in, so one doesn`t have to write alter
Martijn van Oosterhout writes:
> On Tue, Nov 16, 2010 at 10:32:01PM +0200, Peter Eisentraut wrote:
>> On tis, 2010-11-16 at 21:05 +0100, marcin mank wrote:
>>> It would be nice if we could have some mapping of locale names bult
>>> in, so one doesn`t have to write alternative sql depending on DB
>
On Tue, Nov 16, 2010 at 10:32:01PM +0200, Peter Eisentraut wrote:
> On tis, 2010-11-16 at 21:05 +0100, marcin mank wrote:
> > It would be nice if we could have some mapping of locale names bult
> > in, so one doesn`t have to write alternative sql depending on DB
> > server OS:
> > select * from tab
On tis, 2010-11-16 at 21:40 +0100, Pavel Stehule wrote:
> ok, then we should to define this alias manually
>
> some like - CREATE COLLATE "czech" FOR LOCALE "cs_CZ.UTF8"
>
> or some similar. Without this, the application or stored procedures
> can be non portable between UNIX and WIN.
Yes, such
2010/11/16 Peter Eisentraut :
> On tis, 2010-11-16 at 20:59 +0100, Pavel Stehule wrote:
>> 2010/11/16 Peter Eisentraut :
>> > On tis, 2010-11-16 at 20:00 +0100, Pavel Stehule wrote:
>> >> yes - my first question is: Why we need to specify encoding, when only
>> >> one encoding is supported? I can't
On tis, 2010-11-16 at 21:05 +0100, marcin mank wrote:
> It would be nice if we could have some mapping of locale names bult
> in, so one doesn`t have to write alternative sql depending on DB
> server OS:
> select * from tab order by foo collate "Polish, Poland"
> select * from tab order by foo coll
On tis, 2010-11-16 at 20:59 +0100, Pavel Stehule wrote:
> 2010/11/16 Peter Eisentraut :
> > On tis, 2010-11-16 at 20:00 +0100, Pavel Stehule wrote:
> >> yes - my first question is: Why we need to specify encoding, when only
> >> one encoding is supported? I can't to use a cs_CZ.iso88592 when my db
2010/11/16 marcin mank :
>> I can only look at the locales that the operating system provides. We
>> could conceivably make some simplifications like stripping off the
>> ".utf8", but then how far do we go and where do we stop? Locale names
>> on Windows look different too. But in general, how d
> I can only look at the locales that the operating system provides. We
> could conceivably make some simplifications like stripping off the
> ".utf8", but then how far do we go and where do we stop? Locale names
> on Windows look different too. But in general, how do you suppose we
> should map
2010/11/16 Peter Eisentraut :
> On tis, 2010-11-16 at 20:00 +0100, Pavel Stehule wrote:
>> yes - my first question is: Why we need to specify encoding, when only
>> one encoding is supported? I can't to use a cs_CZ.iso88592 when my db
>> use a UTF8 - btw there is wrong message:
>>
>> yyy=# select *
On tis, 2010-11-16 at 20:00 +0100, Pavel Stehule wrote:
> yes - my first question is: Why we need to specify encoding, when only
> one encoding is supported? I can't to use a cs_CZ.iso88592 when my db
> use a UTF8 - btw there is wrong message:
>
> yyy=# select * from jmena order by jmeno collate "
Hello
2010/11/16 Peter Eisentraut :
> On mån, 2010-11-15 at 23:13 +0100, Pavel Stehule wrote:
>> a) default encoding for collate isn't same as default encoding of database
>>
>> it's minimally not friendly - mostly used encoding is UTF8, but in
>> most cases users should to write locale.utf8.
>
>
On mån, 2010-11-15 at 23:13 +0100, Pavel Stehule wrote:
> a) default encoding for collate isn't same as default encoding of database
>
> it's minimally not friendly - mostly used encoding is UTF8, but in
> most cases users should to write locale.utf8.
I don't understand what you are trying to say
Hello
2010/11/15 Peter Eisentraut :
> On mån, 2010-11-15 at 11:34 +0100, Pavel Stehule wrote:
>> I am checking a patch. I found a problem with initdb
>
> Ah, late night brain farts, it appears. Here is a corrected version.
>
>
yes, it's ok now.
I see still a few issues:
a) default encoding for
Hello
I am checking a patch. I found a problem with initdb
[postg...@pavel-stehule postgresql]$ /usr/local/pgsql/bin/initdb -D
/usr/local/pgsql/data/
could not change directory to "/home/pavel/src/postgresql"
The files belonging to this database system will be owned by user "postgres".
This user
> 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
On Wed, Aug 18, 2010 at 11:29 AM, Peter Eisentraut wrote:
> On tis, 2010-08-17 at 01:16 -0500, Jaime Casanova wrote:
>> >> creating collations ...FATAL: invalid byte sequence for encoding
>> >> "UTF8": 0xe56c09
>> >> CONTEXT: COPY tmp_pg_collation, line 86
>> >> STATEMENT: COPY tmp_pg_collation
On tis, 2010-08-17 at 01:16 -0500, Jaime Casanova wrote:
> >> creating collations ...FATAL: invalid byte sequence for encoding
> >> "UTF8": 0xe56c09
> >> CONTEXT: COPY tmp_pg_collation, line 86
> >> STATEMENT: COPY tmp_pg_collation FROM
> >> E'/usr/local/pgsql/9.1/share/locales.txt';
> >> """
>
On Mon, Aug 16, 2010 at 10:56 PM, Peter Eisentraut wrote:
> On lör, 2010-08-14 at 02:05 -0500, Jaime Casanova wrote:
>
>> BTW, why the double quotes?
>
> Because the name contains upper case letters?
>
why everything seems so obvious once someone else state it? :)
>> sorry to state the obvious b
On lör, 2010-08-14 at 02:05 -0500, Jaime Casanova wrote:
> btw, the patch no longer apply cleanly but most are just hunks the
> worst it's in src/backend/catalog/namespace.c because
> FindConversionByName() is now called get_conversion_oid()... so maybe
> this function should be named get_collation
Hi,
sorry for the delay...
btw, the patch no longer apply cleanly but most are just hunks the
worst it's in src/backend/catalog/namespace.c because
FindConversionByName() is now called get_conversion_oid()... so maybe
this function should be named get_collation_oid(), i guess
On Tue, Aug 3, 2010
On mån, 2010-08-02 at 01:43 -0500, Jaime Casanova wrote:
> nowadays, CREATE DATABASE has a lc_collate clause. is the new collate
> clause similar as the lc_collate?
> i mean, is lc_collate what we will use as a default?
Yes, if you do not specify anything per column, the database default is
used.
On Tue, Jul 13, 2010 at 1:25 PM, Peter Eisentraut wrote:
> Here is a proof of concept for per-column collation support.
>
Hi,
i was looking at this.
nowadays, CREATE DATABASE has a lc_collate clause. is the new collate
clause similar as the lc_collate?
i mean, is lc_collate what we will use as
On Thu, Jul 15, 2010 at 4:24 PM, Tom Lane wrote:
> The problem with not doing that is it breaks hashing --- hash joins and
> hash aggregation being the real pain points.
>
> citext works around this in a rather klugy fashion by decreeing that two
> strings are equal iff their str_tolower() convers
Peter Eisentraut writes:
> Well, the comparison function varstr_cmp() contains this comment:
> /*
> * In some locales strcoll() can claim that nonidentical strings are
> * equal. Believing that would be bad news for a number of reasons,
> * so we follow Perl's lead and sort "e
On tor, 2010-07-15 at 05:57 +0200, Pavel Stehule wrote:
> :( maybe we have to enhance a locales - or do some work in this way.
> In Czech's IS is relative often operation some like
>
> name = 'Stěhule' COLLATION cs_CZ_cs_ai -- compare case insensitive
> accent insensitive
>
> PostgreSQL is last d
2010/7/14 Peter Eisentraut :
> On ons, 2010-07-14 at 19:35 +0200, Pavel Stehule wrote:
>> I have only one question - If I understand well you can use collate
>> just for sort. What is your plan for range search operation?
>
> My patch does range searches. Sorting uses the same operators, so both
>
On ons, 2010-07-14 at 19:35 +0200, Pavel Stehule wrote:
> I have only one question - If I understand well you can use collate
> just for sort. What is your plan for range search operation?
My patch does range searches. Sorting uses the same operators, so both
will be supported. (Sorting is not y
Hello
I have only one question - If I understand well you can use collate
just for sort. What is your plan for range search operation? Sort is
interesting and I am sure important for multilangual applications, for
me - more important is case sensitive, case insensitive, accent
sensitive, insensiti
Peter Eisentraut wrote:
> Here is a proof of concept for per-column collation support.
Did you want a WIP review of that patch? (CF closing to new
submissions soon)
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
91 matches
Mail list logo
