Re: [Review] Re: minor patch submission: CREATE CAST ... AS EXPLICIT

Hello Robert,

> I object to this patch. This patch a new keyword, EXPLICIT, for
> reasons that are strictly cosmetic. Everything that you can do with
> this patch can also be done without this patch. It is not a good idea
> to slow down parsing of every SQL statement we have just so that
> someone can write CREATE CAST .. AS EXPLICIT. Granted, the parsing
> slowdown for just one keyword is probably not noticeable, but it's
> cumulative with every new keyword we add. Adding them to support new
> features is one thing, but adding them to support purely optional
> syntax is, I think, going too far.

I partly object to the objection:-)

I agree that it may induce a very small delay to the parser, however I
*do* think that cosmetic things are important. In order to ease
understanding, learning and memorizing a language, concepts must have
names, syntaxes, and be orthogonal and symmetric where applicable.

In this example, there are 3 kinds of casts, all 3 have a conceptual name
(explicit, implicit, assignment) but only two have a syntax, and the other
one is the absence of syntax. So you have to memorize this stupid
information (which one of the three does not have a syntax) or read the
documentation every time to remember that "explicit" is the one without a
syntax. Note also that you must state "implicit" explicitely, but
"explicit" is told implicitely, which does not really help.

The impact is also on the documentation which is not symmetric because it
is based on the syntax which is not, so it is simply a little harder to
understand.

Every year I do my class about PL/pgSQL and extensions to Pg, and every
year some students will try "as explicit" because it is logical to do so.
I think that she is right and that it should work, instead of having to
explain that "explicit" is implicit when dealing with Pg casts. Although
it is my job, I would prefer to spend time explaining more interesting
things.

From the software engineering point of view, having a syntax for all case
means that the developer must think about which kind of cast she really
wants, instead of doing the default thing just because it is the default.

So in my mind the tradeoff is between people time & annoyance and a few
machine cycles, and I have no hesitation to choose the later.

--
Fabien.