Re: Charset/collate support and function parameters

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

In response to

Responses

Browse pgsql-hackers by date

  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