True. Both variants are legal, and most people won't ever notice. I stumbled across this while writing a test case for a transaction helper that sets/restores search_path before committing. The test was to simply compare the string values of `SHOW search_path;` before `BEGIN TRANSACTION;` and after `COMMIT;`.
It's a non-issue, really, but since there's a patch and I cannot come up with a more common use case that would depend on the use of just-comma separators in the default value, I'd say it's more of a question of "why not" instead of "why", isn't it? On 14 July 2014 16:58, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Jul 11, 2014 at 6:09 AM, Christoph Martin > <christoph.r.mar...@gmail.com> wrote: > > I noticed a minor inconsistency with the search_path separator used in > the > > default configuration. > > > > The schemas of any search_path set using `SET search_path TO...` are > > separated by ", " (comma, space), while the default value is only > separated > > by "," (comma). > > > > The attached patch against master changes the separator of the default > value > > to be consistent with the usual comma-space separators, and updates the > > documentation of `SHOW search_path;` accordingly. > > > > This massive three-byte change passes all 144 tests of make check. > > Heh. I'm not particularly averse to changing this, but I guess I > don't see any particular benefit of changing it either. Either comma > or comma-space is a legal separator, so why worry about it? > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
