Thomas Lockhart writes:
> But I'm afraid I'm not recalling the specific issues associated with GUC
> vs no-GUC. What in the current behavior of date and time needs to
> change? Is it locale issues (which for non-ISO date input and output is
> a can of worms by itself) or something else?
One issues was that the semantics of DateStyle don't fit well into GUC.
DateStyle takes one or two strings and sets one or two integer variables.
GUC basically only supports once argument setting one variable of equal
type. It can probably still be made to work with all the hooks that are
in place, but it doesn't look pretty.
I had once suggested splitting up DateStyle into two variables, one for
the "style" and for the day/month order. I think this is ultimately
clearer to the user, too.
Others have suggested generalizing the "style" aspect to take a to_char
format. This comes with its own set of problems.
--
Peter Eisentraut peter_e@gmx.net