From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | sszabo(at)megazone23(dot)bigpanda(dot)com, girgen(at)partitur(dot)se, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Multilingual application, ORDER BY w/ different |
Date: | 2001-11-18 14:17:48 |
Message-ID: | 20011118231748L.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> IIRC, we were debating whether we should consider collation to be an
> attribute of the datatype (think typmod) or an attribute of individual
> values (think field added to values of textual types). In the former
> case, a function like this would only work if we allowed its result to
> be declared as having the right collate attribute. Which is not
> impossible, but we don't currently associate any typmod with function
> arguments or results, and so I'm not sure how painful it would be.
> With the field-in-data-value approach it's easy to see how it would
> work. But another byte or word per text value might be a high price
> to pay ...
I think the price is not so high. To give the collation info to text
data types, it's enough to store the info in the
pg_attribute. ie. only additional several bytes per column are
required, not per instance. Of course we would need to add some extra
bytes to the in-memory string data, it's just a temporary data anyway.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | bpalmer | 2001-11-18 15:17:31 | Re: Call for testing |
Previous Message | Brent Verner | 2001-11-18 12:36:04 | TODO item inquiry/claim |