Re: Boolean output format

From: Jeff Davis <list-pgsql-general(at)empires(dot)org>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Boolean output format
Date: 2002-10-06 01:50:00
Message-ID: 200210051850.00790.list-pgsql-general@empires.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> I was thinking about babelfish when I wrote this!

Wow, that's funny :)

> > 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 brings up another topic. If you have a statically-typed language you need
all the data to come in as one type (intuitively a string). Otherwise you'd
need to know the schema before you wrote the program, and you'd have to
change your variable types when changing a query.

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

Best of luck to you. I hope the solution you come up with after all this is
nice and simple to work with.

> > 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 was being sarcastic, saying that I never have a complete solution, just
little suggestions. I hope it's been some help.

Regards,
Jeff Davis

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Thomas O'Dowd 2002-10-06 03:00:22 understanding insert slowdown
Previous Message Tom Lane 2002-10-06 01:08:28 Re: [INTERFACES] LISTEN/NOTIFY