public inbox for [email protected]help / color / mirror / Atom feed
SELECT List with/without parentheses 5+ messages / 5 participants [nested] [flat]
* SELECT List with/without parentheses @ 2025-09-04 22:32 PG Doc comments form <[email protected]> 0 siblings, 2 replies; 5+ messages in thread From: PG Doc comments form @ 2025-09-04 22:32 UTC (permalink / raw) To: [email protected]; +Cc: [email protected] 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 ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: SELECT List with/without parentheses @ 2025-09-05 21:11 David G. Johnston <[email protected]> parent: PG Doc comments form <[email protected]> 1 sibling, 0 replies; 5+ messages in thread From: David G. Johnston @ 2025-09-05 21:11 UTC (permalink / raw) To: [email protected] <[email protected]>; [email protected] <[email protected]> On Thursday, September 4, 2025, PG Doc comments form <[email protected]> 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. ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: SELECT List with/without parentheses @ 2025-09-05 21:17 Tom Lane <[email protected]> parent: PG Doc comments form <[email protected]> 1 sibling, 1 reply; 5+ messages in thread From: Tom Lane @ 2025-09-05 21:17 UTC (permalink / raw) To: [email protected]; +Cc: [email protected] PG Doc comments form <[email protected]> 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 ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: SELECT List with/without parentheses @ 2025-09-06 00:02 Jason Tiller <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 5+ messages in thread From: Jason Tiller @ 2025-09-06 00:02 UTC (permalink / raw) To: [email protected] 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 <[email protected]> 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 <[email protected]> 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 ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: SELECT List with/without parentheses @ 2025-09-08 07:30 Vik Fearing <[email protected]> parent: Jason Tiller <[email protected]> 0 siblings, 0 replies; 5+ messages in thread From: Vik Fearing @ 2025-09-08 07:30 UTC (permalink / raw) To: Jason Tiller <[email protected]>; [email protected] 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 ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2025-09-08 07:30 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-09-04 22:32 SELECT List with/without parentheses PG Doc comments form <[email protected]> 2025-09-05 21:11 ` David G. Johnston <[email protected]> 2025-09-05 21:17 ` Tom Lane <[email protected]> 2025-09-06 00:02 ` Jason Tiller <[email protected]> 2025-09-08 07:30 ` Vik Fearing <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox