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
