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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Massive regression failures
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Massive regression failures