> 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?
We do require casting functions to follow the Postgres naming
convention. istm to be a waste of time to have the CREATE CAST() feature
*only* set a bit on an existing function, especially given the SQL99
syntax which implies that it can define a cast operation for an
arbitrarily named function. It also supposes that the only allowed casts
are *implicit casts* (see below for a new issue) which is not quite
right. I've defined alternate forms which draw on the general PostgreSQL
feature set and capabilities, but if we can fit the SQL99 model then we
should go ahead and do that too.
I've got another issue with casting which I've run into while testing
this feature; afaict invoking an explicit CAST() in SQL does not
guarantee that the function of the expected name would be called, if
that function does not have the implicit flag set. Seems that it should
be willing to do the conversion even if the function is not marked as
allowing implicit casts; after all, this is an *explicit* cast!
I'm pretty sure that this is the behavior I've been seeing, but will
publish a test case to confirm it when I have a chance.
- Thomas
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
