Well, that's what my disclaimer was for :)
I thought I remembered some rather long discussions about various SETable
variables. I also noticed that the current list of SETable variables is
small. So I kind of put the two together and concluded that the gain from
adding a booleanstyle variable might not be enough to add the extra option.
I don't have any particular argument against the idea, but it kind of worries
me that we'd be headed in the direction of the date/time types. Those seem
complex, and I'd hate to think of boolean as that complex.
Regards,
Jeff Davis
On Friday 04 October 2002 08:43 pm, Tom Lane wrote:
> Jeff Davis <list-pgsql-general@empires.org> writes:
> > The developers tend to like general solutions, like the user-defined data
> > types and the constraints. It's generally pretty difficult to get a new
> > SET variable added, so it's unlikely they'd go for that for just a
> > boolean conversion.
>
> My two cents (not speaking for core or anything like that, just personal
> reaction): my first thought was that SET BOOLEANSTYLE was a reasonable
> idea, seeing as how we have SET DATESTYLE. But on second thought I
> didn't like it so much. Seems like providing such a choice would be
> likely to break those client-side adapters that have gone to the trouble
> of correctly interpreting Postgres booleans into their host languages.
> Those adapters are going to handle 't' and 'f', but in all probability
> they will break if you run them with BOOLEANSTYLE set to anything but
> 'traditional'. So on reflection this feature seems like it will
> penalize the folks who tried to do things right, to reward those who
> couldn't be bothered.
>
> Maybe that's stating it too strongly, but there is a definite backwards-
> compatibility issue to be considered here.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
