Re: Proposal for resolving casting issues

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Proposal for resolving casting issues
Date: 2002-09-18 20:10:21
Message-ID: Pine.LNX.4.44.0209172112170.1307-100000@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane writes:

> On looking more closely, SQL99 appears to define user-defined casts as
> invocable *only* in explicit cast and assignment contexts.

> This seems to mean that we can get away with defining AS ASSIGNMENT to
> mean my second category (implicit in assignment only), and then picking
> some more natural term for my first category (implicit anywhere).

Sounds good.

Have you seen 9.4 "Subject routine determination" and 9.5 "Type
precedence list determination"? In essence, the SQL standard has a
hard-coded precedence list much like we have. Since we support the
creation of non-structured user-defined types, the additional castability
level effectively gives us a way to override the built-in precedence
lists. In fact, now that we have given up in the numeric/float8
precedence, the other hard-coded categories should be easy to eliminate.

> CREATE CAST (sourcetype AS targettype)
> WITH FUNCTION funcname (argtype)
> [ AS ASSIGNMENT | IMPLICIT ]

Fine with me.

--
Peter Eisentraut peter_e(at)gmx(dot)net

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2002-09-18 20:11:08 AIX compilation problems (was Re: Proposal ...)
Previous Message Peter Eisentraut 2002-09-18 20:09:51 Re: RPMS for 7.3 beta.