Thread: Re: [HACKERS] KSQO parameter
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: 16 June 2002 01:09 > To: Tom Lane > Cc: PostgreSQL-development; PostgreSQL odbc list > Subject: Re: [ODBC] [HACKERS] KSQO parameter > > > either ... does anyone out there want to work on it? > > The following patch removes KSQO from GUC and the call to the > function. It also moves the main KSQO file into _deadcode. Applied. > > ODBC folks, should I remove KSQO from the ODBC driver? I'm not sure that Hiroshi has updated CVS with all our recent changes just yet - there is certainly a patch outstanding that redesigns the setup dialogues that I posted that would be affected by this... Regards, Dave.
Dave Page wrote:
>
> > -----Original Message-----
> > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> > Sent: 16 June 2002 01:09
> > To: Tom Lane
> > Cc: PostgreSQL-development; PostgreSQL odbc list
> > Subject: Re: [ODBC] [HACKERS] KSQO parameter
> >
> > > either ... does anyone out there want to work on it?
> >
> > The following patch removes KSQO from GUC and the call to the
> > function. It also moves the main KSQO file into _deadcode. Applied.
> >
> > ODBC folks, should I remove KSQO from the ODBC driver?
>
> I'm not sure that Hiroshi has updated CVS with all our recent changes
> just yet
Sorry I've had no time to see it.
> - there is certainly a patch outstanding that redesigns the
> setup dialogues that I posted that would be affected by this...
I don't object to remove the KSQO option at server side.
But why must the option be removed from the odbc driver
together ? As I mentioned many many times, the driver
isn't only for the recent (especially not yet released)
version of servers. I think we had better have a separate
dialog for obsolete options.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
Hiroshi Inoue wrote: > > - there is certainly a patch outstanding that redesigns the > > setup dialogues that I posted that would be affected by this... > > I don't object to remove the KSQO option at server side. > But why must the option be removed from the odbc driver > together ? As I mentioned many many times, the driver > isn't only for the recent (especially not yet released) > version of servers. I think we had better have a separate > dialog for obsolete options. Yes, this is why I am asking. If you want to keep it for <7.1 releases, that is fine. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Hello everbody.
I have started work on native OLE DB Provider for PostgreSQL. i think it is
really important to have native OLE DB proviader even if there is OLE DB to
ODBC Provider. Microsoft started to withdraw support for ODBC and seems to
force to switch to OLE DB(eg VS .Net have limited support for ODBC which
must be spearetly downloaded), so we could expect more such moves. So I
started work on native PostgreSQL OLE DB provider. It slowly begin
to work. (it registers to system, shows property pages, connects to
database, and do first quries). Now I'm working on creating resultset.
I would like somebody to help answer some questions:
1.is it safe to use binary cursors (basic types format e.g date would not
change in future)
2.how could I control result type (binary/ASCII) for ordinary SELECTS ?
3.could ODBC driver mix auto-commit and FETCH/DECLARE mode ? how it can
handle such situation:
start select (fetch some data) /as I understand it should start
transaction silently/
update (it should commit as we are in auto-commit)
fetch more data.
next update (commit again)
4. maybe it would have sense to make some common library with ODBC to handle
prepared statements and some kind of conversions (althougth maybe not
becouse we convert to different types (OLE DB uses OLE Automation types))
5. Is there any way to truncate PQresult in libpq ? I implement fast forward
cursors so i have no need to store whole result (I can read piece of data
and forget it when client read it from me). I think there would be no
problem if I add some PQtruncate(PQresult *) to pqlib, but maybe there is
any different way ?
I use ATL templates for OLE DB which is MS library and it can't be compiled
withot Visual Studio. (you have right to distribute ATL if you bougth VS).
So It would be not "pure" solution, but starting from scratch is to
difficult, as I don't know COM prefectly. Maybe somebody will rewrite it
later.
Are you aware that another team on the list is working on a .Net provider? Maybe you could work with them? .Net Provider people: speak up! Chris > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Marek Mosiewicz > Sent: Monday, 17 June 2002 4:34 PM > To: PostgreSQL-development; PostgreSQL odbc list > Subject: [HACKERS] Native OLE DB. What do you think about it > > > Hello everbody. > > I have started work on native OLE DB Provider for PostgreSQL. i > think it is > really important to have native OLE DB proviader even if there is > OLE DB to > ODBC Provider. Microsoft started to withdraw support for ODBC and seems to > force to switch to OLE DB(eg VS .Net have limited support for ODBC which > must be spearetly downloaded), so we could expect more such moves. So I > started work on native PostgreSQL OLE DB provider. It slowly begin > to work. (it registers to system, shows property pages, connects to > database, and do first quries). Now I'm working on creating resultset. > > I would like somebody to help answer some questions: > > 1.is it safe to use binary cursors (basic types format e.g date would not > change in future) > 2.how could I control result type (binary/ASCII) for ordinary SELECTS ? > 3.could ODBC driver mix auto-commit and FETCH/DECLARE mode ? how it can > handle such situation: > start select (fetch some data) /as I understand it should start > transaction silently/ > update (it should commit as we are in auto-commit) > fetch more data. > next update (commit again) > 4. maybe it would have sense to make some common library with > ODBC to handle > prepared statements and some kind of conversions (althougth maybe not > becouse we convert to different types (OLE DB uses OLE Automation types)) > 5. Is there any way to truncate PQresult in libpq ? I implement > fast forward > cursors so i have no need to store whole result (I can read piece of data > and forget it when client read it from me). I think there would be no > problem if I add some PQtruncate(PQresult *) to pqlib, but maybe there is > any different way ? > > I use ATL templates for OLE DB which is MS library and it can't > be compiled > withot Visual Studio. (you have right to distribute ATL if you bougth VS). > So It would be not "pure" solution, but starting from scratch is to > difficult, as I don't know COM prefectly. Maybe somebody will rewrite it > later. > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
"Marek Mosiewicz" <marekmosiewicz@poczta.onet.pl> writes:
> 1.is it safe to use binary cursors (basic types format e.g date would not
> change in future)
Don't do it. The internal representations are NOT guaranteed stable,
and moreover any such thing will guarantee that your code can not talk
to servers running on non-Intel architectures. (I'm sure MS/Intel
would love you to do that, but don't.)
> 2.how could I control result type (binary/ASCII) for ordinary SELECTS ?
You can't, but it doesn't matter, see above.
regards, tom lane
> "Marek Mosiewicz" <marekmosiewicz@poczta.onet.pl> writes: > > 1.is it safe to use binary cursors (basic types format e.g date would not > > change in future) > > Don't do it. The internal representations are NOT guaranteed stable, > and moreover any such thing will guarantee that your code can not talk > to servers running on non-Intel architectures. (I'm sure MS/Intel > would love you to do that, but don't.) So I will not. But any way is it difficult to froze basic types. I believe that producing and parsing data takes some time both on server and client. Acctually it is question about prepared statements, but I think it is not pay off. It can take some time to parse parameters if you have many same queries updates (very common situation e.g. sending back inserts/ updates from client). you could then : 'Qselect * from a where a=? and b=?P<binary parameters> <return binary result> update a set x=? where y=?P<array of parameters - make the same query nth times with different values> Such prepared statments would not only benefit from cached plan but also avoidance of parameter parsing and sending it - multiple times across network -. Most DB intefaces has some support for such batch execution so it could be used (OLE DB JDBC) in it and gain speed) It could be easy do decide to use exclusive little or big indian - such conversion is many times faster than atoi(). I don't know if it is problem to froze binary representaion of data but if it is not frozen then you could never use bianry cursor from client). I have no idea how diffcult it would be to implement so I don't know if it it has sense, but it is only my propostion. > > > 2.how could I control result type (binary/ASCII) for ordinary SELECTS ? > > You can't, but it doesn't matter, see above. > > regards, tom lane