Re: SELECT List with/without parentheses
On Thursday, September 4, 2025, PG Doc comments form 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.
Adding clarification on extension_control_path when extension is present in multiple folders
When playing with the new GUC extension_control_path, I found that the paths are evaluated one by one (like search_path)and if an extension is present in multiple paths, only the on in the first path will be considered.I think this is totally fine, but I'd like to adda documentation patch to explain this (attached file). What do you think ? Pierrick, Here is an example to understand that I can only create extension in version 2.0. postgres=# show extension_control_path ; extension_control_path - $system:/extensions/meilleureextension/share:/extensions/monextension/share (1 row) postgres=# select * from pg_available_extensions where name like '%mon%'; name | default_version | installed_version | comment --+-+---+--- monextension | 2.0 | | Meilleure monextension | 1.0 | | Mon extension (2 rows) postgres=# select * from pg_available_extensions where name like '%mon%'; name | default_version | installed_version | comment --+-+---+--- monextension | 2.0 | | Meilleure monextension | 1.0 | | Mon extension (2 rows) postgres=# create extension monextension version "1.0" ; ERROR: extension "monextension" has no installation script nor update path for version "1.0" postgres=# create extension monextension ; CREATE EXTENSION postgres=# select * from pg_available_extensions where name like '%mon%'; name | default_version | installed_version | comment --+-+---+--- monextension | 2.0 | 2.0 | Meilleure monextension | 1.0 | 2.0 | Mon extension (2 rows) From d04af9866d9eddea04b046005df3b2cdc99b28ec Mon Sep 17 00:00:00 2001 From: Pierrick Chovelon Date: Fri, 5 Sep 2025 15:36:20 +0200 Subject: [PATCH] Add clarification on extension_control_path --- doc/src/sgml/config.sgml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 0a4b3e55ba5..752d18dec53 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -11079,6 +11079,12 @@ extension_control_path = '/usr/local/share/postgresql:$system' dynamic_library_path = '/usr/local/lib/postgresql:$libdir' + + +This variable specifies the order in which extensions are searched when created. +If an extension is present in multiple paths, only the first path that contains +extension's files will be used. + -- 2.43.0
Re: SELECT List with/without parentheses
PG Doc comments form 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
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
