Re: [INTERFACES] Re: ODBC driver and Dates - Mailing list pgsql-interfaces

On Sat, 18 Apr 1998, Hannu Krosing wrote:

> Gerhard Reithofer wrote:
> >
> > Hi Hackers,
> >

... deleted some older stuff ...
> > I cannot aggree fully.
> >
> > In my applications, there are many data imports and exports from the Unix
> > side and Windows side. They normally should look identically.
> >
> > Another way of representing data is often the pure ascii way - i. e. how
> > it is sent from the server (e. g. in the older PostODBC versions). A
> > simple text viewer may be used the display the data.
>
> It has nothing to do with representation, but how data is transferred
> between client and server. The representation is done et a completely
> different level. It is due to PostgreSQL lacking a common universal
> binary transfer format that these problems have emerged in the first
> place - there is no sharp distinction between internal protocol and
> external representation.
>
> 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).

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

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.

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

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

I think we have the same goal but are just discussing about the way :-)

Bye
    Gerhard

+-----------------+             +--- gerhardr@tech-edv.co.at ---+
| Technische EDV   \ Reithofer / Technical Sofware Developement |
| A-2136 Laa/Thaya  \ Gerhard / Tel +43-2522/8726 +-------------+
| Staatsbahnstr. 100 +-------+ Fax +43-2522/87268 |
+----- http://members.aon.at/tech-edv/Info -------+