Re: plpgsql variable assignment not supporting distinct anymore

From: easteregg(at)verfriemelt(dot)org
To: "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
Subject: Re: plpgsql variable assignment not supporting distinct anymore
Date: 2021-01-22 13:41:06
Message-ID: 20210122134106.e94c5cd7@mail.verfriemelt.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

the code provided is just a little poc to get the error ( which i have not included with my first mail sorry. )

ERROR: syntax error at or near "DISTINCT"
LINE 8: _test := DISTINCT a FROM ( VALUES ( (true), ( true ) ) )...

the code in production looked like this:

_resource_id :=
DISTINCT ti_resource_id
FROM tabk.resource_timeline
WHERE ti_a2_id = _ab2_id
AND ti_type = 'task'
;

this is backed up by a trigger function, that will ensure to every instance with the same ti_a2_id exists only one ti_resource_id, hence the query can never fail due to more than one row beeing returned. but this syntax is not supported anymore, which will break BC. up until PG 13, the assignment statement was just an implizit SELECT <expression> Query.
Since Tom Lane didn't mentioned this change in the other thread, i figured the devteam might not be aware of this chance.

i can refactor this line into

_resource_id :=
ti_resource_id
FROM tabk.resource_timeline
WHERE ti_a2_id = _ab2_id
AND ti_type = 'task'
GROUP BY ti_resource_id
;

but concerns about BC was already raised, although with UNION there might be far less people affected.
with kind regards, richard

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2021-01-22 13:50:04 Re: Some more hackery around cryptohashes (some fixes + SHA1)
Previous Message Alvaro Herrera 2021-01-22 13:39:00 Re: LogwrtResult contended spinlock