From: | Viktor Holmberg <v(at)viktorh(dot)net> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: ISN extension - wrong volatility level for isn_weak() function |
Date: | 2025-03-14 14:28:01 |
Message-ID: | de89bd5c-9f51-4891-8a38-d03ed06ebd1d@Spark |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I haven’t checked the source code, but yes the isn_weak feature has some footgun potential. As it doesn’t respect transactions, but rather sets a flag on session level, it’s easy for the “isn weakness” to leak out into a connection pool.
Still the feature is very useful as I work with many suppliers who give us product lists full of invalid EANs, which still need to be ingested.
/Viktor
On 14 Mar 2025 at 14:16 +0000, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, wrote:
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> > On 14 Mar 2025, at 12:49, Viktor Holmberg <v(at)viktorh(dot)net> wrote:
> > > The isn_weak function in the isn extension reports the wrong value if you look at it inside a transaction:
>
> > I wonder if this should really be marked VOLATILE instead as it has a side
> > effect.
>
> Indeed. This whole area seems really poorly considered. The comment
> in isn--1.1.sql says
>
> -- isn_weak(boolean) - Sets the weak input mode.
> -- This function is intended for testing use only!
>
> despite which it's documented at length in isn.sgml. On the other
> hand, so far as I can find it's tested nowhere, which means none
> of the "weak mode" code is getting exercised.
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-03-14 14:32:04 | Re: BUG #18850: REDUNDANT_COMPARISON.ALWAYS_FALSE Redundant comparison |
Previous Message | Tom Lane | 2025-03-14 14:27:07 | Re: BUG #18848: DEREF_AFTER_NULL.EX.COND After having been compared to a NULL |