Обсуждение: SELECT List with/without parentheses
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. Thank you for the wonderful work you do! ---Jason
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](…).
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],
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 painfuldebugging 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 "principleof 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