On 22 May 2011 07:27, Fabien COELHO <coe...@cri.ensmp.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers