Re: Boolean output format

on 10/4/02 8:43 PM, Tom Lane at tgl(at)sss(dot)pgh(dot)pa(dot)us wrote:

> Jeff Davis <list-pgsql-general(at)empires(dot)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.

Tom,

Thanks for chiming in! I was hoping you were listening.

Were there any backward compatibility issues for SET DATESTYLE? What were
the repercussions for the adapters? That seems more likely to have had
problems than SET BOOLSTYLE. Interestingly, the date formats in PostgreSQL
and MySQL are identical. At least for me, the boolean was always a greater
problem.

Regarding the existing adapters - I very much agree with what you're saying,
but such a feature would not necessarily break any existing adapters. The
default format would remain unchanged and the event that an end user were to
use the brand-new feature with a brand-new distibution of PostgreSQL, I
don't think they will hold it against the team if it didn't work with their
adapter - as long as it was easy to restore the default and it didn't break
anything if left unused.

If there were a SET BOOLSTYLE, it's mainly the php folks that will be
thanking the postgresql folks. Not to mention the php/mysql->postgres
converts who are spared the extra work of porting hundreds of booleans in
their applications! I'd be the first one to express my gratitude!

I don't think this is a question of reward vs. punishment, but maybe more
one of a where the responsibility should fall... If an RDBMS returns only
textual data, it does not necessarily imply that the adapter should be
interpreting this data. If some adapters do, it need not imply that all
adapters should. Lastly, if the RDBMS offers options, not all adapters need
to support them, and they have the choice either way. I don't see the harm
in providing the choice as long as it does not limit any existing choices in
the existing platforms.

I don't know if php's treatment of database results is incorrect, but I like
the fact that my queries in php return exactly the same results as my
queries in the psql client! I work with them in tandem, and I appreciate the
transparency of php's adapter! I'd like to think that the php developers
made a conscious decision to leave the data alone. I don't really see
anything wrong with that, but I'm not familiar with the conventions of
writing database drivers.

All I know is that if there is a gap between the two platforms, it should be
in the best interest of both camps to fill it, and I don't think there need
be any price to pay other than a little elbow grease. I hold the work that
goes into PostgreSQL as well as PHP in very high regard.

Once again, thanks very much for the feedback!
Garo.

>
> 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
>

=-=-==-=-=-==

Xapnet Internet Solutions
1501 Powell St., Suite N
Emeryville, CA 94608

Tel - (510) 655-9771
Fax - (510) 655-9775
Web - http://www.xapnet.com