Re: Sanding down some edge cases for PL/pgSQL reserved words - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Sanding down some edge cases for PL/pgSQL reserved words
Date
Msg-id 2223186.1745637024@sss.pgh.pa.us
Whole thread Raw
In response to Re: Sanding down some edge cases for PL/pgSQL reserved words  ("Joel Jacobson" <joel@compiler.org>)
Responses Re: Sanding down some edge cases for PL/pgSQL reserved words
List pgsql-hackers
"Joel Jacobson" <joel@compiler.org> writes:
> For years, I've felt we could benefit from introducing convenience syntax to
> explicitly require that exactly one row is affected by a query, something which
> currently requires using a somewhat cumbersome workaround:

> - Using `... INTO STRICT ...` for `SELECT`,
> - Using `RETURNING ... INTO STRICT ...` for `DELETE/UPDATE/INSERT`, or
> - Checking `ROW_COUNT` via `GET DIAGNOSTICS` and raising an error if not exactly one row.

> I think it would be more convenient and intuitive if we could simply write:

> ```
> STRICT [SELECT | UPDATE | INSERT | DELETE] ...;
> ```

Meh.  I don't really have an opinion on whether this is worth bespoke
syntax, but if it is:

(1) I don't see why we'd restrict it to plpgsql as opposed to
implementing it in core SQL.

(2) Putting the keyword at the front seems fairly un-SQL-like.
For SELECT, "SELECT STRICT ..." would seem more natural, as it calls
back to SELECT DISTINCT; or you could imagine integrating it into the
LIMIT clause.  Not as sure what to do for the DML commands, but
somewhere near where we put RETURNING seems saner.

Also, even if we did do it in plpgsql exactly as you suggest, making
it unreserved doesn't move the needle on whether that's possible.
Most of plpgsql's statement-starting keywords are unreserved.

But please, don't hijack this thread for that discussion ...

            regards, tom lane



pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: Re: Sanding down some edge cases for PL/pgSQL reserved words
Next
From: Bertrand Drouvot
Date:
Subject: Avoid circular header file dependency