From: Hannu Krosing <hannu@trust.ee>
To: Gerhard Reithofer <gerhardr@tech-edv.co.at>
Cc: Aleksey Demakov <avd@avd.garsib.ru>
Cc: pgsql-interfaces@postgreSQL.org, byronn@insightdist.com, Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [INTERFACES] Re: ODBC driver and Dates
Date: Sat, 18 Apr 1998 13:10:44 +0300
Message-ID: <35387C24.43F04F82@sid.trust.ee> (raw)
References: <Pine.LNX.3.95.980417211253.1610C-100000@at486>
Gerhard Reithofer wrote:
>
> Hi Hackers,
>
> On 17 Apr 1998, Aleksey Demakov wrote:
>
> > Byron Nikolaidis <byronn@insightdist.com> writes:
> >
> > > Should the driver query the database (i.e., "show datestyle") to see what format
> > > it should use, -OR-, should it be an option for the datasource, where you select
> > > what style to use, and the driver sets the style when it makes a connection
> > > ("set datestyle")?
> >
> > I beleave there is no need for such an option. The only thing is
> > needed that ODBC-driver and Postgres use the same format during
> > connection. Thus opening connection ODBC-driver should always set
> > the datestyle which it uses. Asking the datestyle from backend and
> > than using appropriate conversion is posible but why to bother with
> > this while the opposite (instructing backend what datestyle to use)
> > is much simpler to implement and will work equaly well?
>
> 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 think that getting a common network-neutral binary format should also
be in the TODO. Bruce?
> I personally would like to controll the transfer and translations as data
> source options.
It is much better to have _one_ encoding on wire. It adds _nothing_ but
complexity if you have several encodings there - the only way to see it
is from some debugging logs anyway.
> IMHO the way Byron implemented special featured is great, but these should
> be DOCUMENTED features.
After Byrons letter they are ;)
> An input field in the data source setup dialog
> could be used to define these "pre-connect statements". And I think there
> are some other UNDOCUMENTED features, which would be very usefull (take a
> look at the source)!
>
> 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!
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, avd@avd.garsib.ru, maillist@candle.pha.pa.us
Subject: Re: [INTERFACES] Re: ODBC driver and Dates
In-Reply-To: <35387C24.43F04F82@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