Skip site navigation (1) Skip section navigation (2)

Re: [INTERFACES] Re: ODBC driver and Dates

From: Hannu Krosing <hannu(at)trust(dot)ee>
To: Gerhard Reithofer <gerhardr(at)tech-edv(dot)co(dot)at>
Cc: Aleksey Demakov <avd(at)avd(dot)garsib(dot)ru>, pgsql-interfaces(at)postgreSQL(dot)org, byronn(at)insightdist(dot)com, Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Subject: Re: [INTERFACES] Re: ODBC driver and Dates
Date: 1998-04-18 10:10:44
Message-ID: 35387C24.43F04F82@sid.trust.ee (view raw or flat)
Thread:
Lists: pgsql-interfaces
Gerhard Reithofer wrote:
> 
> Hi Hackers,
> 
> On 17 Apr 1998, Aleksey Demakov wrote:
> 
> > Byron Nikolaidis <byronn(at)insightdist(dot)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

In response to

Responses

pgsql-interfaces by date

Next:From: Hannu KrosingDate: 1998-04-18 10:33:00
Subject: Re: [INTERFACES] Naming of the PostreSQL ODBC .dll file
Previous:From: Gerhard ReithoferDate: 1998-04-18 09:44:15
Subject: Re: [INTERFACES] Naming of the PostreSQL ODBC .dll file

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group