Re: SQL99, CREATE CAST, and initdb

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

In response to

Responses

Browse pgsql-hackers by date

  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