<div dir="ltr">I was trying to sort out the problem with not creating new catalog for character sets and I came up
followingideas. Correct me if my ideas are wrong.<br /><br />Since collation has to have a defined character set I'm
suggestingto use already written infrastructure of encodings and to use list of encodings in chklocale.c. Currently
databasesare not created with specified character set but with specified encoding. I think instead of pointing a record
incollation catalog to another record in character set catalog we might use only name (string) of the encoding.<br
/><br/>So each collation will be set over these encodings set in chklocale.c. Each database will be able to use only
collationsthat are created over same ("compatible") encodings regarding encoding_match_list. Each standard collation
(SQLstandard) will be defined over all possible encodings (hard-coded). <br /><br />Comments?<br /><br />Regards<br
/><br/> Radek Strnad<br /><br /><div class="gmail_quote">On Sat, Jul 12, 2008 at 5:17 PM, Tom Lane <<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>wrote:<br /><blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div
class="Ih2E3d">ZdenekKotala <Zdenek.Kotala@Sun.COM> writes:<br /> > I think if we support UTF8 encoding, than
itmake sense to create own charsets,<br /> > because system locales could have defined collation for that.<br /><br
/></div>Saywhat? I cannot imagine a scenario in which a user-defined encoding<br /> would be useful. The amount of
infrastructureyou need for a new<br /> encoding is so large that providing management commands is just silly<br /> ---
anyonewho can create the infrastructure can do the last little bit<br /> for themselves. The analogy to index access
methodsis on point, again.<br /><br /> regards, tom lane<br /></blockquote></div><br /></div>
