Re: Native OLE DB. What do you think about it
От | Marek Mosiewicz |
---|---|
Тема | Re: Native OLE DB. What do you think about it |
Дата | |
Msg-id | 003c01c21613$ceef63a0$206516ac@2210446 обсуждение исходный текст |
Ответ на | Re: [ODBC] KSQO parameter ("Dave Page" <dpage@vale-housing.co.uk>) |
Список | pgsql-hackers |
> "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
В списке pgsql-hackers по дате отправления: