Re: minor patch submission: CREATE CAST ... AS EXPLICIT

On 22 May 2011 07:27, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>
> 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.
>

Hi Fabien,

I'm taking a look at this patch for the commitfest. On first reading
of the patch, it looked pretty sensible to me, but I had some trouble
applying it to HEAD:

error: patch failed: doc/src/sgml/ref/create_cast.sgml:20
error: doc/src/sgml/ref/create_cast.sgml: patch does not apply
error: patch failed: src/backend/parser/gram.y:499
error: src/backend/parser/gram.y: patch does not apply
error: patch failed: src/include/parser/kwlist.h:148
error: src/include/parser/kwlist.h: patch does not apply
error: patch failed: src/test/regress/expected/create_cast.out:27
error: src/test/regress/expected/create_cast.out: patch does not apply
error: patch failed: src/test/regress/sql/create_cast.sql:27
error: src/test/regress/sql/create_cast.sql: patch does not apply

Perhaps the patch could use a refresh?

Also, for what it's worth, I buy into the argument for adding AS
EXPLICIT. This stuff is all an extension to the SQL standard already;
it might as well have a well-rounded syntax.

Cheers,
BJ