From: Hannu Krosing <hannu@trust.ee>
To: Gerhard Reithofer <gerhardr@tech-edv.co.at>
Cc: Hannu Krosing <hannu@trust.ee>
Cc: pgsql-interfaces@postgreSQL.org, Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [INTERFACES] Re: ODBC driver and Dates
Date: Sat, 18 Apr 1998 18:25:08 +0300
Message-ID: <3538C5D4.6861D4B3@sid.trust.ee> (raw)
References: <Pine.LNX.3.95.980418154848.3469A-100000@at486>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: hannu@trust.ee, gerhardr@tech-edv.co.at, maillist@candle.pha.pa.us
Subject: Re: [INTERFACES] Re: ODBC driver and Dates
In-Reply-To: <3538C5D4.6861D4B3@sid.trust.ee>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox