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
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. |