Re: SQL99, CREATE CAST, and initdb - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SQL99, CREATE CAST, and initdb
Date
Msg-id 21127.1024951411@sss.pgh.pa.us
Whole thread Raw
In response to Re: SQL99, CREATE CAST, and initdb  (Thomas Lockhart <lockhart@fourpalms.org>)
List pgsql-hackers
Thomas Lockhart <lockhart@fourpalms.org> writes:
>> 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.

Urk.  Do you realize how expensive SQL functions are for such uses?
(I have had a to-do item for awhile to teach the planner to inline
trivial SQL functions, but it seems unlikely to happen for another
release or three.)

I see no real reason why we should not require casting functions to
follow the Postgres naming convention --- after all, what else would
you name a casting function?

So I'm with Peter on this one: make the SQL99 syntax a mere wrapper
for setting the IMPLICIT CAST bit on an existing function.  Otherwise,
people will avoid it as soon as they discover what it's costing them.
        regards, tom lane




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Use of LOCAL in SET command
Next
From: Tony Griffiths
Date:
Subject: Re: ADTs and embedded sql