Обсуждение: 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.
AFAICS, we have the following problem constructions:
================================
a IS DISTINCT FROM b
a IS NOT DISTINCT FROM b
a IN (...)
a NOT IN (...)
CASE a WHEN b THEN ... ELSE d END
NULLIF(a, b)
JOIN USING / NATURAL JOIN
a IS NOT DISTINCT FROM b
a IN (...)
a NOT IN (...)
CASE a WHEN b THEN ... ELSE d END
NULLIF(a, b)
JOIN USING / NATURAL JOIN
================================
As a quick recap, the following options are available to us.
1) Add the "USING operator" clause.
Rejected due to:
* Non-standard syntax.
* ruleutils.c could not safely convert this back to the source text.
* In case "IS DISTINCT FROM" on composite types, using only the eq operator is maybe not enough.
Rejected due to:
* Non-standard syntax.
* ruleutils.c could not safely convert this back to the source text.
* In case "IS DISTINCT FROM" on composite types, using only the eq operator is maybe not enough.
2) Using default btree opclass/opfamily operators.
Rejected due to:
* Adding yet another way of selecting an operator to the existingfunc_select_candidate and opfamily
* Adding yet another way of selecting an operator to the existingfunc_select_candidate and opfamily
seems too complicated and not safe.
* May not work in some cases.
* May not work in some cases.
3) CVE-2018-1058 revert.
Rejected due to obvious reasons.
Rejected due to obvious reasons.
In my humble opinion, the best way to solve an issue is (1). Whether it's even worth it. Although it
uses non-standard syntax, it does not break the existing one.
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.