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

From Joel Jacobson
Subject Re: Sanding down some edge cases for PL/pgSQL reserved words
Date
Msg-id 96a02132-f65f-4a3c-b322-69724ebe7fc7@app.fastmail.com
Whole thread Raw
In response to Sanding down some edge cases for PL/pgSQL reserved words  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Sanding down some edge cases for PL/pgSQL reserved words
List pgsql-hackers
On Sat, Apr 26, 2025, at 06:44, Tom Lane wrote:
> This is a rather delayed response to the discussion of bug
> #18693 [1], in which I wrote:
...
> which is pretty bogus because the record *does* have a field
> named "strict".  The actual problem is that STRICT is a fully
> reserved PL/pgSQL keyword, which means you need to double-quote
> it if you want to use it this way.

I'd like to briefly raise an old nostalgic PL/pgSQL dream of mine that might be
affected by this change.

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] ...;
```

That is, allowing `STRICT` followed directly by any regular `SELECT`, `UPDATE`,
`INSERT`, or `DELETE` command, explicitly enforcing exactly one affected row.

Changing `STRICT` to become an unreserved keyword in PL/pgSQL would effectively
close the window of opportunity for this syntax, as it would introduce ambiguity
in command parsing.

I was actually not aware of STRICT already being a reserved PL/pgSQL keyword.
Had I known that, I would have proposed this convenience syntax already since
a long time ago.

I wonder how often developers truly need to use "strict" as a field name versus
the potential usage of a clean and explicit syntax for enforcing single-row
results without additional verbosity.

/Joel



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Adding pg_dump flag for parallel export to pipes
Next
From: Tom Lane
Date:
Subject: Re: Sanding down some edge cases for PL/pgSQL reserved words