Message-ID: <3538C5D4.6861D4B3@sid.trust.ee>
Date: Sat, 18 Apr 1998 18:25:08 +0300
From: Hannu Krosing <hannu@trust.ee>
MIME-Version: 1.0
To: Gerhard Reithofer <gerhardr@tech-edv.co.at>
CC: Hannu Krosing <hannu@trust.ee>, pgsql-interfaces@postgreSQL.org,
	Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [INTERFACES] Re: ODBC driver and Dates
References: <Pine.LNX.3.95.980418154848.3469A-100000@at486>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Gerhard Reithofer wrote:
> 
> >
> > I think it was not meant to be that way at first, as there are special
> > placed reserved in pg_type for both type conversion functions :
> > typinput/typoutput (presumably machine dependent ones) and
> > typreceive/typsend (presumably network-neutral ones),
> > somehow they are always the same .
> 
> I still cannot agree!
> 
> I didn't study V6.3 in detail, but at least until 6.2 all user data has
> been transfered in an ASCII byte by byte order (not mentioning blobs).

This is because ASCII is for now the only platform independant format ;(

There is at least one place where BINARY cursor helps - namely
determining 
the real defined maximum length on varchar fields.
 
> Translation into a platform dependant representation (like a binary
> date...) is always done inside the (ODBC) driver. That's the reason why we
> have all the mapping disussions - of the char types, date/time, money ...

We would need the mappings anyhow, even if it would ne and INT<->INT
mapping.

> The main problem of any ODBC implementation is that you have all freedom
> to implement almost any conversion as you like - and many programmers,
> incl. MS itself - do not follow common rules, but they EXPECT a specific
> translation. This is the reason for many errors which are mostly specific
> to ONE application in ONE version on ONE platform.

They not only expect a specific translation but they even have a date
datatype ;)

What I was advocating, was to always force the driver-level transfers in
the 
same format, not just guess and use what the locale specific format
happens to be.

> > I think that getting a common network-neutral binary format should also
> > be in the TODO. Bruce?
> ... an old, old discussion - remembering byte order... ;-)

The byte order (which ended up the non-standard way) was about the 
protocol itself, not the data which should not be fixed but extensible.

> > > And last, some type of mapping table could be used to controll the
> > > different *CHAR* mappings between the server and the frontend applications
> > > (but I don't have a detailed idea how to implement this). This could be
> > > the end of the NAME<>CHAR<>BPCHAR<>VARCHAR<>LONGVARCHAR... discussions.
> >
> > That would be a nice feature indeed!
> 
> This could be a common approach and should also include date/time/money...
> but would make much, much work :-(

So it is better to _not_ include anything we don't absolutely need at
the 
protocol level. The less clutter we have here the better. 

I repeat once more - this has nothing to do with what the user sees or 
what the database stores. It is just what is transferred over wire.

-----
Hannu