Re: Proposal: CREATE CONVERSION

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: lockhart(at)fourpalms(dot)org
Cc: peter_e(at)gmx(dot)net, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal: CREATE CONVERSION
Date: 2002-07-09 06:23:35
Message-ID: 20020709.152335.40590967.t-ishii@sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > If so, what about the "coercibility" property?
> > The standard defines four distinct coercibility properties. So in
> > above my example, actually you are going to define 80 new types?
> > (also a collation could be either "PAD SPACE" or "NO PAD". So you
> > might have 160 new types).
>
> Well, yes I suppose so. The point is that these relationships *must be
> defined anyway*. Allowed and forbidden conversions must be defined,
> collation order must be defined, indexing operations must be defined,
> etc etc etc. In fact, everything typically associated with a type must
> be defined, including the allowed conversions between other types
> (character sets/collations).
>
> So, how are we going to do this *in a general way* without carrying the
> infrastructure of a (the) type system along with it? What would we be
> able to leave out or otherwise get for free if we use another mechanism?
> And is that mechanism fundamentally simpler than (re)using the type
> system that we already have?

Well, I think charset/collation/coercibility/pad are all string data
type specific properties, not common to any other data types. So it
seems more appropreate for type systems not to have those certain type
specific knowledges. For example,

S1 < S2

should raise an error if S1 has "no collating properties" and S2 has
"implicit collating properties", while ok if S1 has "no collating
properties" and S2 has "explicit collating properties". It would be
very hard for the type system to handle this kind of cases since it
requires special knowledges about string data type.

Alternative?

Why don't we have these properties in the string data itself?
(probably we do not need to have them on disk storage). Existing text
data type has length + data. I suggest to extend it like:

length + charset + collation + pad + coercibility + data

With this above example could be easily handled by < operator.

For index, maybe we could dynamically replace varstr_cmp function
according to collation, though I have not actually examined my idea
closely.
--
Tatsuo Ishii

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2002-07-09 06:46:40 Re: Proposal: CREATE CONVERSION
Previous Message Hannu Krosing 2002-07-09 06:19:42 Re: Issues Outstanding for Point In Time Recovery (PITR)