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

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: [Review] Re: minor patch submission: CREATE CAST ... AS EXPLICIT
Дата
Msg-id alpine.DEB.2.02.1306222128000.23902@localhost6.localdomain6
обсуждение исходный текст
Ответ на Re: [Review] Re: minor patch submission: CREATE CAST ... AS EXPLICIT  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
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.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: dump difference between 9.3 and master after upgrade
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: [Review] Re: minor patch submission: CREATE CAST ... AS EXPLICIT