Re: Add RANGE with values and exclusions clauses to the Window Functions

Поиск
Список
Период
Сортировка
От Oliver Ford
Тема Re: Add RANGE with values and exclusions clauses to the Window Functions
Дата
Msg-id CAGMVOdtJZCXQRO1HQvGWTfzxrP0cTtxWXfXJ58EC2f2GgSQ+9w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add RANGE with values and exclusions clauses to the Window Functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Add RANGE with values and exclusions clauses to the Window Functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers


On Monday, 29 January 2018, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Oliver Ford <ojford@gmail.com> writes:
> [ 0001-window-frame-v9.patch ]

I've started to go through this in some detail, and I'm wondering why
you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than
just representing that choice as default (0).  As you have it, a
window definition that explicitly specifies EXCLUDE NO OTHERS will be
considered unequal to one that just defaults to that behavior, in
e.g. transformWindowFuncCall().  That seems undesirable, if not
outright wrong.  Against that, having the bit allows ruleutils.c
to print "EXCLUDE NO OTHERS" when the input included that, but that
seems like a wash if not an anti-feature.  We've never been big on
making ruleutils output distinguish explicit from implicit selection
of a default setting, and in this case it could possibly lead to
outputting a query in a form that is not backwards-compatible to
older PG versions, when there's no need to be incompatible.

Exclude No Others does seem pretty pointless to me, but it's in the standard so I included it as an option that can be printed by ruleutils. I can't imagine it being much used, but if people do want to document that they are not excluding other rows they can do so.

My guess is that it's a little like putting "ORDER BY x ASC" when ASC is usually default behavior - it adds some documentation, perhaps for people new to SQL or to make your intention more explicit. That's the only reason I can think of as to why the standards committee included it.


If there's some other consideration I'm missing, please say what;
otherwise I'll change it.

BTW, I generally recommend not including a catversion change in
submitted patches.  It causes merge problems any time some other
catversion-bumping patch gets committed, and it can't possibly be
the right value for the final commit since you aren't likely to
be able to predict that date in advance.  It surely doesn't hurt
to remind the committer that a catversion bump is needed, but just
do that in the submission message.

Ok won't do that again. 

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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: JIT compiling with LLVM v9.0
Следующее
От: Andres Freund
Дата:
Сообщение: Re: JIT compiling with LLVM v9.0