Hello Tom,
>> Add "AS EXPLICIT" to "CREATE CAST" This gives a name to the default
>> case of "CREATE CAST", which creates a cast which must be explicitely
>> invoked.
>
> I'm not sure this is a good idea. The CREATE CAST syntax is in the SQL
> standard, and this isn't it. Now I realize that we've extended that
> statement already to cover some functionality that's not in the
> standard, but that doesn't mean we should create unnecessarily
> nonstandard syntax for cases that are in the standard.
The standard provides only one case, so "CAST" is good enough a name.
Once you start creating alternatives with distinct semantics, then it
helps to give the initial one a name as well to be able to discuss them
with something else that "the remaining case", or "when there is no
option", especially as there is something to discuss.
Note that the standard is still supported just the same, and the
documentation already underlines that "AS *" stuff is a pg extension,
nothing is really changed. Maybe the documentation could be clearer about
where the standard stops and where extensions start, even now without an
"AS EXPLICIT" clause.
> If a commercial vendor did that, wouldn't you castigate them for trying
> to create vendor lock-in?
I'm more concerned with explaining things to students, and its good to
have words and logic for that.
With respect to the standard, it seems good enough to me if (1) the
standard is well supported and (2) the documentation clearly says which
parts are extensions. If you really want to keep to the standard, then do
not offer any extension.
Moreover, this stuff is really minor compared to RULEs or many other
things specifics to pg, and the "lock-in" is light, you just have to
remove "AS EXPLICIT" to get away, no big deal.
Well, you decide anyway:-)
Have a nice day,
--
Fabien.
