Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - didsomething change? CASE WHEN behavior oddity

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - didsomething change? CASE WHEN behavior oddity
Дата
Msg-id 20170604211942.aiavcbagsho5owcz@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity  (Mark Dilger <hornschnorter@gmail.com>)
Ответы Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity  (Mark Dilger <hornschnorter@gmail.com>)
Список pgsql-hackers
On 2017-06-04 14:16:14 -0700, Mark Dilger wrote:
> Sorry, I was not clear.  What I meant to get at was that if you remove from the
> executor all support for SRFs inside case statements, you might foreclose the option
> of extending the syntax at some later date to allow aggregates over
> SRFs.

Seems very unlikely that we'd ever want to do that.  The right way to do
this is to simply move the SRF into the from list.  Having the executor
support arbitrary sources of tuples would just complicate and slow down
already complicated and slow code...


> I'm
> not saying that this works currently, but in principle if you allowed that SUM() that
> I put up there, you'd get back exactly one row from it, same as you get from the
> ELSE clause.  That would seem to solve the problem without going so far as
> completely disallowing the SRF altogether.

But what would the benefit be?


Greetings,

Andres Freund



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

Предыдущее
От: Mark Dilger
Дата:
Сообщение: Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity
Следующее
От: Tom Lane
Дата:
Сообщение: [HACKERS] Make ANALYZE more selective about what is a "most common value"?