Re: Boolean output format

on 10/5/02 8:59 AM, Tom Lane at tgl(at)sss(dot)pgh(dot)pa(dot)us wrote:

> Garo Hussenjian <garo(at)xapnet(dot)com> writes:
>> Were there any backward compatibility issues for SET DATESTYLE? What were
>> the repercussions for the adapters?
>
> Can't say. It's been there for longer than I've been around this
> project; and AFAIR no new values of DATESTYLE have been added in a long
> time either. You might try asking Tom Lockhart.
>
>> 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
>
> ... not if someone decides to set BOOLEANSTYLE at the postgresql.conf
> level, or in the per-user or per-database options that are available in
> 7.3. Realistically, general-purpose client-side code is going to need
> to work with any style that the backend might emit.
>
Couldn't you make the same argument for the adapters?

I understand. I'm a little concerned about the performance implications of
processing all booleans individually versus setting the style globally in
the backend. There is a great deal of replication and additional overhead
that I don't think should have to be necessary. I guess it has to happen
somewhere. I'm going to try switching to the native bool and manually update
boolean f's with FALSE and see what happens! It will work, but it's ugly IMO
and I'd still love to see this feature in postgresql.

I'd really like to know if this option would in fact break any of the common
libraries? I'd be willing to help in any way I can.

> You might compare the discussions that have gone on in the past month or
> so, since I (overhastily) added some backend support for an auto-commit
> off mode. I knew very well that the client libraries were mostly not
> prepared to work with that, but I figured we could update them over
> time. Judging from the volume of complaints, that was a bad decision.
> So I'm applying that experience to this issue with booleans ...

Agreed, but perhaps that was a more drastic change? My vote would be to put
it into a development tree and let it get tested until we at least know IF
it will break any client libraries.

Would you at least agree that the current situation is one of a subtle but
"costly" incompatibility between postgresql and php? Of course there are
workarounds, but they are not ideal.

Also, is it really the case that the adapters (JDBC, DBI, others) actually
process database output? I think maybe the languages are doing this. Maybe
we should be looking at the languages rather than the adapters to predict if
there are problems?

Garo.

>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>

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

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

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