On Mon, Jun 30, 2025 at 8:49 AM Maxim Orlov 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 real
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
As a quick recap, the following op
On Mon, 23 Jun 2025 at 19:28, Tom Lane wrote:
> Maxim Orlov 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" g
Maxim Orlov 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
Hi!
Imagine that I need to use custom operators for one of the table fields in
a "simple case"
and let these operators not be in a default scheme. As far as I understand,
the only way
to specify the operator in this case is to use the search path.
In the example below, this corresponds to column
