Re: Proposal for resolving casting issues - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Proposal for resolving casting issues
Date
Msg-id Pine.LNX.4.44.0209172112170.1307-100000@localhost.localdomain
Whole thread Raw
In response to Re: Proposal for resolving casting issues  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@gmx.net



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: AIX compilation problems (was Re: Proposal ...)
Next
From: Peter Eisentraut
Date:
Subject: Re: Open 7.3 items