From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | db(at)zigo(dot)dhs(dot)org |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Charset/collate support and function parameters |
Date: | 2004-10-31 01:17:33 |
Message-ID: | 20041031.101733.35014451.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Sat, 30 Oct 2004, Tom Lane wrote:
>
> > > The alternative is storing the charset and collation inside each string.
> > > That seems like a too big price to pay, it belong in the type.
> >
> > No, the alternative you're proposing is too big a price to pay.
>
> So you want to expand every string with 8 bytes (two oid's)?
For me that seems to be the right way. I'm not sure if two oids are
the right solution but we need to store extra info in varlena
structure to support charset/collation anyway. In my understanding
TOAST has already done in similar way.
Other than charset/collation we also need coercibility info to meet
with the SQL standard. This could only be represented in each text,
not by function parameters.
> Or special case the storing in tables so that you only store the text and
> not the charset/collation info?
On disk representation we don't need charset/collation since they will
be stored in probably pg_attribute. Coercibility info is not necessary
on disk too.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2004-10-31 03:52:37 | not null partial index? |
Previous Message | Markus Bertheau | 2004-10-30 21:55:48 | Re: array_to_column function |