Re: [PATCH] Fix search_path default value separator.

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 <robertmhaas(at)gmail(dot)com> wrote:

> On Fri, Jul 11, 2014 at 6:09 AM, Christoph Martin
> <christoph(dot)r(dot)martin(at)gmail(dot)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
>