> > It doesn't match perfectly in that one field is ignored as being
> > (afaict) redundant for us. The basic definition from SQL99 is
> > CREATE CAST(from AS to) WITH FUNCTION func(args) [AS ASSIGNMENT]
> > I can map this to something equivalent to
> > CREATE FUNCTION to(from) RETURNS to AS 'select func($1)' LANGUAGE 'sql';
> > with another clause or two to get the implicit coersion enabled, and
> > ignoring the "args" field(s).
> I think this is wrong. When you call CREATE CAST ... WITH FUNCTION
> func(args) then func(args) must already exist.
Right. And that is what is required for SQL99 also afaict. There are not
enough clauses in the SQL99 syntax to allow anything else!
> So the closest you could
> map it to would be
> ALTER FUNCTION to(from) IMPLICIT CAST
That would require that the function to be used as the cast have the
same name as the underlying PostgreSQL conventions for casting
functions. The implementation I've done does not require this; it
basically defines a new SQL function with a body of
select func($1)
where "func" is the name specified in the "WITH FUNCTION func(args)"
clause. It does hang together in the way SQL99 intends and in a way
which is consistant with PostgreSQL's view of the world.
But, I've also implemented alternate forms which would allow one not
define a separate function beforehand. So the nice PostgreSQL feature of
allowing function names to be different than the entry points can be
used.
> iff the name of the function and the target data type agree. (Of course
> this command doesn't exit, but you get the idea.) The SQL99 feature is
> more general than ours, but in order to use if effectively we would need
> to maintain another index on pg_proc. Tom Lane once opined that that
> would be too costly.
I don't follow you here, but the implementation I have is consistant
with SQL99 (or at least with the way I'm interpreting it :)
- Thomas
