On Sat, Aug 02, 2008 at 03:39:18PM +0200, Radek Strnad wrote:
> > I also think that the clauses you have attached to your CREATE
> > COLLATION statement (case-insensitive, accent-insensitive) are an
> > oversimplification of reality. I suggest you look up the Unicode
> > collation algorithm to le
Hello,
the main reason why I've submitted the patch was to start a discussion and
know other people's opinion on this problem.
On Tue, Jul 29, 2008 at 10:41 AM, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
>
> Where are the collations going to come from?
There will be two new catalogs - pg_coll
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> In my opinion, you are starting this project from the wrong end. I would
> suggest you approach it like this:
>
> - Find some collation implementations
> - Patch PostgreSQL to link with them
Well I think the feeling is that we may as well start w
Am Tuesday, 1. July 2008 schrieb Radek Strnad:
> I'm sending part of the code that I've done and is available for reviewing
> and I'm asking for your comments and some help because I'm new to
> PostgreSQL.
>
> Proposal: http://archives.postgresql.org/pgsql-hackers/2008-05/msg00857.php
>
> The code
Martijn van Oosterhout napsal(a):
On Tue, Jul 08, 2008 at 09:05:11PM +0200, Zdenek Kotala wrote:
All the argument here is based on the premise that we should have
database-level collation specifications, which AFAICS is not required
nor suggested by the SQL spec.
Yeah, it is not required, but b
On Tue, Jul 08, 2008 at 09:05:11PM +0200, Zdenek Kotala wrote:
> >All the argument here is based on the premise that we should have
> >database-level collation specifications, which AFAICS is not required
> >nor suggested by the SQL spec.
>
> Yeah, it is not required, but by my opinion it should
Andrew Dunstan napsal(a):
Tom Lane wrote:
All the argument here is based on the premise that we should have
database-level collation specifications, which AFAICS is not required
nor suggested by the SQL spec. I wonder why we are allowing a
nonstandard half-measure to drive our thinking, rath
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Martijn van Oosterhout napsal(a):
Not necessarily. pg_class is not shared yet without it you can't even
find pg_database. Same deal with pg_type. All it means is that
pg_collation in template1 must contain all the collations used in
Josh Berkus <[EMAIL PROTECTED]> writes:
> Andrew, Tom,
>> Agreed. Are we even sure that we want per-database collations as a
>> half-way house? Unless we can be sure that we want all the required
>> catalog changes for the full requirement, it seems to me a rather messy
>> way of getting to where w
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
... And of course shared tables need also collation for their indexes.
No, they don't, because the only textual indexes on shared catalogs are
on "name" columns, which are intentionally not locale aware, and
wouldn't be collation aw
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Martijn van Oosterhout napsal(a):
Not necessarily. pg_class is not shared yet without it you can't
even
find pg_database. Same deal with pg_type. All it means is that
pg_collation in template1 must contain all the collations used in
t
Andrew, Tom,
> Agreed. Are we even sure that we want per-database collations as a
> half-way house? Unless we can be sure that we want all the required
> catalog changes for the full requirement, it seems to me a rather messy
> way of getting to where we want to go.
Given that we don't have a del
On Tue, Jul 08, 2008 at 10:54:28AM -0400, Andrew Dunstan wrote:
> Agreed. Are we even sure that we want per-database collations as a
> half-way house? Unless we can be sure that we want all the required
> catalog changes for the full requirement, it seems to me a rather messy
> way of getting to
Tom Lane wrote:
All the argument here is based on the premise that we should have
database-level collation specifications, which AFAICS is not required
nor suggested by the SQL spec. I wonder why we are allowing a
nonstandard half-measure to drive our thinking, rather than solving the
real pr
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> ... And of course shared tables need also collation for their indexes.
No, they don't, because the only textual indexes on shared catalogs are
on "name" columns, which are intentionally not locale aware, and
wouldn't be collation aware either.
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout napsal(a):
>> Not necessarily. pg_class is not shared yet without it you can't even
>> find pg_database. Same deal with pg_type. All it means is that
>> pg_collation in template1 must contain all the collations used in
>> template1,
Martijn van Oosterhout napsal(a):
Oh I see, you're referring to the storage of the default collation for
a database. I was jumping ahead to the per-column collation state, when
the collation default is attached to columns, types and domains, and
not at the database level. So there the problem do
On Tue, Jul 08, 2008 at 12:00:34PM +0200, Zdenek Kotala wrote:
> >Not necessarily. pg_class is not shared yet without it you can't even
> >find pg_database. Same deal with pg_type. All it means is that
> >pg_collation in template1 must contain all the collations used in
> >template1, which shouldn'
Martijn van Oosterhout napsal(a):
On Tue, Jul 08, 2008 at 11:27:35AM +0200, Zdenek Kotala wrote:
Zdenek Kotala napsal(a):
I though more about it and I discussed it with Radek yesterday. The
problem is that collation must be created before user want to use CREATE
DATABASE ... COLLATE ... comma
On Tue, Jul 08, 2008 at 11:27:35AM +0200, Zdenek Kotala wrote:
> Zdenek Kotala napsal(a):
>
> >
> >I though more about it and I discussed it with Radek yesterday. The
> >problem is that collation must be created before user want to use CREATE
> >DATABASE ... COLLATE ... command. It inclines to h
Zdenek Kotala napsal(a):
I though more about it and I discussed it with Radek yesterday. The
problem is that collation must be created before user want to use CREATE
DATABASE ... COLLATE ... command. It inclines to have have pg_collation
as a global catalog, but ANSI specifies to use schema
Tom Lane napsal(a):
Gregory Stark <[EMAIL PROTECTED]> writes:
Out of curiosity, what is a "user-defined collation"? Are there SQL statements
to go around declaring what order code points should be sorted in? That seems
like it would be... quite tedious!
We might be best off to treat colla
Tom Lane napsal(a):
Gregory Stark <[EMAIL PROTECTED]> writes:
Out of curiosity, what is a "user-defined collation"? Are there SQL statements
to go around declaring what order code points should be sorted in? That seems
like it would be... quite tedious!
Hm, that's a good point. SQL99 has
Gregory Stark <[EMAIL PROTECTED]> writes:
> Out of curiosity, what is a "user-defined collation"? Are there SQL statements
> to go around declaring what order code points should be sorted in? That seems
> like it would be... quite tedious!
Hm, that's a good point. SQL99 has
::=
My patch should be "sort of" wrapper that will implement guts for further
development (collation at column level) like catalogs, creating collations
etc. When creating collation user will be able to choose which function to
use (by statement STRCOLFN - not in SQL standard). In the first stage I'll
On Wed, Jul 02, 2008 at 07:22:10PM +0100, Gregory Stark wrote:
> > Because the SQL spec says so. Also, if we don't put them in schemas,
> > we have no nice way to distinguish built-in and user-defined collations,
> > which creates a problem for pg_dump.
>
> Out of curiosity, what is a "user-defin
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Why does a collation have a schema?
>
> Because the SQL spec says so. Also, if we don't put them in schemas,
> we have no nice way to distinguish built-in and user-defined collations,
> which creates a problem
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Why does a collation have a schema?
>
> Because the SQL spec says so. Also, if we don't put them in schemas,
> we have no nice way to distinguish built-in and user-defined collations,
> which creates a problem for pg_dump.
Oh, I
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Why does a collation have a schema?
Because the SQL spec says so. Also, if we don't put them in schemas,
we have no nice way to distinguish built-in and user-defined collations,
which creates a problem for pg_dump.
regards, tom
Radek Strnad escribió:
> 2) What type should all names in CREATE and DROP statement in gram.y have?
> I've chosen qualified_name but I know it's not the best choice.
I think it should be ColId.
> 3) All collations are created from existing collations. How do I ensure that
> the collation already
Hello,
I'm sending part of the code that I've done and is available for reviewing
and I'm asking for your comments and some help because I'm new to
PostgreSQL.
Proposal: http://archives.postgresql.org/pgsql-hackers/2008-05/msg00857.php
The code contains changes of parser, pg_collation catalog, p
31 matches
Mail list logo
