From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Thomas Lockhart <thomas(at)fourpalms(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: GUC vs variable.c (was Patches applied...) |
Date: | 2002-04-21 23:57:05 |
Message-ID: | 29063.1019433425@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> The only thing that I had suggested on occasion was that if nontrivial
> work were to be put into SET DATESTYLE, we might want to consider if a
> certain amount of "cleanup" could be done at the same time. For example,
> the particular date styles have somewhat unfortunate names, as does the
> "european" option. And the parameter could be separated into two. One
> doesn't have to agree with these suggestions, but without them the work is
> sufficiently complicated that no one has gotten around to it yet.
I think you were mainly concerned that we not define two interacting
GUC variables (ie, setting one could have side-effects on the other)?
I don't see any inherent reason that DATESTYLE couldn't be imported into
GUC as-is. The semantics might be uglier than you'd like, but why would
they be any worse than they are now?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2002-04-21 23:59:20 | Re: GUC vs variable.c (was Patches applied...) |
Previous Message | Tom Lane | 2002-04-21 23:53:47 | Re: GUC vs variable.c (was Patches applied...) |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2002-04-21 23:59:20 | Re: GUC vs variable.c (was Patches applied...) |
Previous Message | Tom Lane | 2002-04-21 23:53:47 | Re: GUC vs variable.c (was Patches applied...) |