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

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: minor patch submission: CREATE CAST ... AS EXPLICIT
Date: 2011-05-21 21:27:42
Message-ID: alpine.DEB.2.02.1105212300190.12292@localhost6.localdomain6
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2011-05-21 21:47:56 about EDITOR_LINENUMBER_SWITCH
Previous Message Kevin Grittner 2011-05-21 21:06:48 Re: SSI predicate locking on heap -- tuple or row?