Re: [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet

Поиск
Список
Период
Сортировка
От Nikolay Shaplov
Тема Re: [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet
Дата
Msg-id 1868585.jcgsxskSny@nataraj-amd64
обсуждение исходный текст
Ответ на Re: [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
В письме от 24 мая 2016 12:47:20 пользователь Tom Lane написал:
> Nikolay Shaplov <n.shaplov@postgrespro.ru> writes:
> > If I read gram.y code for insert statement, I see that there is an
> > optional
> > USING keyword before opclass name
> >
> > opt_class:  any_name                                { $$ = $1; }
> >
> >             | USING any_name                        { $$ = $2; }
> >             | /*EMPTY*/                             { $$ = NIL; }
> >
> >         ;
> >
> > but it the documentation this keyword is omitted.
>
> I think we should seriously consider fixing this code/docs discrepancy
> by making the code match the docs, not vice versa.  That is, let's just
> remove the USING alternative here entirely.
>
> If we wanted to make the docs match the code, it would not only be
> CREATE INDEX that would have to be patched, because that's not the
> only place that index_elem can appear.  As far as I can find in a
> quick search, none of the relevant statements have ever documented
> that USING is allowed here; nor does it appear that any client-side
> code of ours makes use of the keyword.
>
> Also, because USING is already used elsewhere in CREATE INDEX (to
> introduce the optional index AM name), I think that documenting its
> use in this clause would add confusion not subtract it.  References
> to "the USING clause in CREATE INDEX" would become ambiguous.
>
> This wouldn't be something to back-patch, of course, but I think it's
> an entirely reasonable change to make in HEAD.
>
> Comments?

I have two arguments for not removing USING there.

1. Backward compatibility. Are you sure, that nobody ever wrote a code using
this "USING" keyword? I would say it is unlikely, but will not be sure 100%.
Dropping this backward compatibility (even with small chance that it was ever
used) for no practical reason is not wise at all. If it might bring some pain
to somebody, then why do it after all...

2. I think expression with USING in it is more human readable:

CREATE INDEX (xxx op_yyy);

is less sensible then

CREATE INDEX (xxx USING op_yyy);

in my opinion. In second example person that does not know SQL at all, will
understand that xxx is main object or action, and op_yyy is about how this xxx
will be done or used.

If somebody would like to write more readable code, why we should forbid it to
him?

2.1. As far as I can get the general idea of SQL, there is a tendency to put
keywords (optional or not) between to object names. Like this

SELECT a _AS_ b from ....

I like this tendency

2.2. I am not familiar with SQL ISO standart, and I suppose there is no USING
at all in that case, but I think it would be good to look there to check for
it or for something similar

2.3. And the last, when I found out about this keyword, I started to use it in
my SQL statements that I use while development, and I just liked it. I will
miss it if you remove it ;-)


--
Nikolay Shaplov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company



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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)
Следующее
От: Nikolay Shaplov
Дата:
Сообщение: Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind