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_collate
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 learn
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
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 with the
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 be
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
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!
snip
We might be best off to treat
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
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 have have
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 ...
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't be
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
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, which
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.
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
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
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
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
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 aware
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 we want to
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
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,
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
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
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
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 see :-)
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 for pg_dump.
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-defined
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
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
collation
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,
31 matches
Mail list logo
