Thread: Re: Issue with custom operator in simple case
Maxim Orlov <orlovmg@gmail.com> writes:
> 1) Can this behaviour, in the case described above, when after dump and
> recovery we receive different data, be considered correct?
It's undesirable, for sure.
> 4) Does it make sense to extend the "simple case" grammar so that it can
> accept a custom operator?
This has been discussed before, see e.g. [1][2]. Unfortunately CASE
is just the tip of the iceberg, there are several SQL constructs that
are equally underspecified. Fixing them all looks messy, and it would
cause dumps to be even less portable than they are now. So nobody's
stepped up to tackle the issue.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/20141009200031.25464.53769%40wrigleys.postgresql.org
[2] https://www.postgresql.org/message-id/flat/10492.1531515255%40sss.pgh.pa.us#8755318d9b16ec32296398f0893a44d7
On Mon, 23 Jun 2025 at 19:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Maxim Orlov <orlovmg@gmail.com> writes:
> 1) Can this behaviour, in the case described above, when after dump and
> recovery we receive different data, be considered correct?
It's undesirable, for sure.
> 4) Does it make sense to extend the "simple case" grammar so that it can
> accept a custom operator?
This has been discussed before, see e.g. [1][2]. Unfortunately CASE
[1] https://www.postgresql.org/message-id/flat/20141009200031.25464.53769%40wrigleys.postgresql.org
[2] https://www.postgresql.org/message-id/flat/10492.1531515255%40sss.pgh.pa.us#8755318d9b16ec32296398f0893a44d7
Thank you for pointing this out. I'll have to read those discussions.
--
Best regards,
Maxim Orlov.
On Mon, Jun 30, 2025 at 8:49 AM Maxim Orlov <orlovmg@gmail.com> wrote:
3) CVE-2018-1058 revert.Rejected due to obvious reasons.
Not revert but maybe try again at convincing people that DBAs should be given agency here by opting out of a security system that breaks functioning code without providing, in reality, any immediate security benefit.
David J.