Re: Boolean output format

on 10/5/02 2:41 AM, Jeff Davis at list-pgsql-general(at)empires(dot)org wrote:
>
> Ah, I think I finally get it. You go MySQL->PostgreSQL->MySQL and end up with
> something a little different. Reminds me of some stories I've heard about
> online text translators like Babelfish :)
>
> That's certainly a good point.

I was thinking about babelfish when I wrote this!

>
>>
>> As for the MySQL thing, it uses 1/0 and as a result remains consistent with
>> the php convention for booleans. I guess that's just the trade-off when
>> using a dynamically typed language... I suppose I think of postgresql as
>> the final destination for my data, and I'd like to think that the
>> language/interface that I choose doesn't really matter. Regardless of the
>> interface, I'd like to "communicate" with postgres directly if possible!
>
> I don't think you can really get any responses from postgres except in the
> form of a NUL-terminated string. I suppose you could store binary data in a
> bytea attribute, but that seems like a lot of work. You can't just bring a
> byte from the internal data representation of the type into your application
> directly.

:) I didn't mean THAT directly! There was a good deal of discussion about
what adapters are supposed to do in order to bring data into the program
environment. I just meant that I like having a transparent adapter. The
downside is that if the database can't adjust the format, with an adapter
like php's, we are left to pick up the pieces in our code.

This has been an interesting side topic... Should databases accommodate
multiple output formats? I think it'd be nice, but I'm now less inclined to
say yes than I was at the beginning of this conversation. I am now leaning
toward a middleware solution. I have a php app-server project that has done
a good deal in terms of db abstraction and I think I just didn't consider it
to be the "responsibility" of my code to do this. I'm now thinking that if
php's native pgsql drivers don't do it, and postgres isn't going to do it,
the we have to do it. In this case, The application server is the place to
do it. Maybe when I implement this model I can post it for pg-php developers
can have a slightly easier life!

>
> Oh, and you might take a look into using the system catalogs to determine
> attribute types in your app. That would at least make it possible for you to
> know how to convert.
>
> Well, I'm certainly good at coming up with almost-solutions, aren't I? :)

You certainly have provided several thoughtful solutions! Thank you.

I think this whole thing is just an argument for better php middleware. In
the absence of this, I can see that it's just up to me to provide the
abstraction - you know, this may even represent an opportunity in the php
marketplace!

My think this last solution actually works best - to use the db-native
types, that is boolean in both cases, and deal with the system tables for to
get the types. I will cache the schema and use it to pre-process my query
results. So should I expand boolean t/f to 1/0 or TRUE/FALSE in the php
environment? Decisions, decisions! :)

Regards,
Garo.

>
> Regards,
> Jeff Davis
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)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