Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity |
Дата | |
Msg-id | 7181.1496458380@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - didsomething change? CASE WHEN behavior oddity (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - didsomething change? CASE WHEN behavior oddity
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > On 2017-05-28 14:03:26 -0400, Tom Lane wrote: >> I think it would be possible to teach eval_const_expressions that >> it must not discard CASE/COALESCE subexpressions that contain SRFs, >> which would preserve the rule that expression simplification doesn't >> change the query semantics. > That sounds like a good idea. Do you want to write up a patch, or > should I? I can, but I'd want to finish the walsender panic and other > signal handling stuff first (mostly waiting for review for now). I think you've got enough on your plate. I can take care of whatever we decide to do here. What I was looking for was opinions on which way to address it. >> Another possibility is to say that we've broken this situation >> irretrievably and we should start throwing errors for SRFs in >> places where they'd be conditionally evaluated. That's not real >> nice perhaps, but it's better than the way things are right now. > I'd be ok with that too, but I don't really see a strong need so far. The argument for this way is basically that it's better to break apps visibly than silently. The behavior for SRF-inside-CASE is not going to be the same as before even if we implement the fix I suggest above, and it's arguable that this new behavior is not at all intuitive. I'm not really sure which way to jump, which is why I was hoping for some discussion here. regards, tom lane
В списке pgsql-hackers по дате отправления: