SELECT List with/without parentheses

On Thursday, September 4, 2025, PG Doc comments form <noreply@postgresql.org>
wrote:

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/17/sql-select.html
Description:

Here: https://www.postgresql.org/docs/current/sql-select.html

There is no mention of the difference in PostgreSql behavior if the select
list of columns is surrounded by parentheses or not. The difference is
quite
dramatic and non-obvious, especially when working with a database driver
(like pq or pqxx) where the result is packed up in a fairly opaque object.
Just some mention of how using parentheses causes a query to return a "row"
object that represents the tuple as a single string vs not using
parentheses
where each column is represented individually.

That kind of material usually goes in the syntax chapter since it isn’t
special to a select command or really any command in particular.

The documentation does explain that to create a row-like composite from
individual columns you use [row](…).

https://www.postgresql.org/docs/current/sql-expressions.html#SQL-SYNTAX-ROW-CONSTRUCTORS

The select command itself states what it does: each column - and the column
list is not parenthesized - becomes a column in the result.

I admit it’s definitely not easy to try making up some new syntax, finding
that it works, then looking for the feature in the documentation from the
syntax alone. But that is also not usually how one learns. In short, I’m
against updating “select” but would entertain some other concrete
suggestion since I don’t find this scenario rare enough to just ignore and
deal with via Q&A.

David J.

PG Doc comments form <noreply@postgresql.org> writes:

There is no mention of the difference in PostgreSql behavior if the select
list of columns is surrounded by parentheses or not.

What you've written there is an implicit row constructor, that is
"(a,b,...)" is taken as "ROW(a,b,...)". These are documented at [1]https://www.postgresql.org/docs/current/sql-expressions.html#SQL-SYNTAX-ROW-CONSTRUCTORS,
but it would be quite unwieldy to point out the possibility of this
for every context in which it could be written.

Personally I think implicit row constructors were one of the SQL
committee's worst ideas, precisely because of the surprise factor.
But it's in the standard so we're stuck with it.

regards, tom lane

[1]: https://www.postgresql.org/docs/current/sql-expressions.html#SQL-SYNTAX-ROW-CONSTRUCTORS

Hi, Tom,

Thanks for your feedback! I'm a SQL newbie and the "implicit row constructor" syntax was an unwelcome surprise. I guess painful debugging is one way to cement a concept...

Seems like this is a nothing-burger and probably has no place in the PostgreSql documentation. Although I feel like the "principle of least surprise" has been violated here. :/

I appreciate the info!

---Jason

On Fri, Sep 5, 2025, at 2:17 PM, Tom Lane wrote:

PG Doc comments form <noreply@postgresql.org> writes:

There is no mention of the difference in PostgreSql behavior if the select
list of columns is surrounded by parentheses or not.

What you've written there is an implicit row constructor, that is
"(a,b,...)" is taken as "ROW(a,b,...)". These are documented at [1],
but it would be quite unwieldy to point out the possibility of this
for every context in which it could be written.

Personally I think implicit row constructors were one of the SQL
committee's worst ideas, precisely because of the surprise factor.
But it's in the standard so we're stuck with it.

regards, tom lane

[1]
https://www.postgresql.org/docs/current/sql-expressions.html#SQL-SYNTAX-ROW-CONSTRUCTORS

On Fri, Sep 5, 2025, at 2:17 PM, Tom Lane wrote:

PG Doc comments form <noreply@postgresql.org> writes:

There is no mention of the difference in PostgreSql behavior if the select
list of columns is surrounded by parentheses or not.

What you've written there is an implicit row constructor, that is
"(a,b,...)" is taken as "ROW(a,b,...)". These are documented at [1],
but it would be quite unwieldy to point out the possibility of this
for every context in which it could be written.

Personally I think implicit row constructors were one of the SQL
committee's worst ideas, precisely because of the surprise factor.
But it's in the standard so we're stuck with it.

regards, tom lane

[1]
https://www.postgresql.org/docs/current/sql-expressions.html#SQL-SYNTAX-ROW-CONSTRUCTORS

On 06/09/2025 02:02, Jason Tiller wrote:

Thanks for your feedback! I'm a SQL newbie and the "implicit row constructor" syntax was an unwelcome surprise.

The reason for it is so you can write WHERE (a, b) > (1, 2) and similar.

Perhaps WHERE ROW(a, b) > ROW(1, 2) would have been better, perhaps not.

--

Vik Fearing