| From: | "Regina Obe" <lr(at)pcorp(dot)us> |
|---|---|
| To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "'Mark Dilger'" <hornschnorter(at)gmail(dot)com>, "'Andres Freund'" <andres(at)anarazel(dot)de>, "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity |
| Date: | 2017-06-08 15:57:49 |
| Message-ID: | 000501d2e06f$faeca490$f0c5edb0$@pcorp.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> But this line of thinking does strengthen my feeling that throwing an
error is the right thing to do for the moment. If we allow v10 to accept
such cases but do something different from what we used to, that
> will greatly complicate any future attempt to try to restore the old
behavior.
> regards, tom lane
Agreed. The other side benefit of throwing an error instead of just doing
something different is you'll find out how rampant the old behavior is :).
People are more likely to know to complain when their apps break than they
are if it just silently starts doing something different.
My main concern in these cases is the short-circuiting not happening.
Because in these cases, the code goes into areas that it shouldn't which is
likely to mess up some logic in hard to troubleshoot ways.
I think erroring out is the best compromise.
Thanks,
Regina
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2017-06-08 16:31:55 | Re: Long binded parameter value in the postgres log |
| Previous Message | David G. Johnston | 2017-06-08 15:39:06 | Re: List of hostaddrs not supported |