From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SQL99, CREATE CAST, and initdb |
Date: | 2002-06-24 20:43:31 |
Message-ID: | 21127.1024951411@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Lockhart <lockhart(at)fourpalms(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Kalchev | 2002-06-24 20:47:10 | oids rollover? |
Previous Message | Tom Lane | 2002-06-24 20:37:50 | Re: Use of LOCAL in SET command |