[ too tired to respond to the other points, but: ]
Shay Rojansky writes:
>> It's also possible for a type not to have send/recv functions, i.e. to
>> support text-only use.
> In that case, what would be the behavior of selecting such a type with an
> extended query that specifies "all results in
Thanks for all the answers.
Tom:
> FWIW, I'd go with text results, especially if you already have code to
> deal with that. PG's on-the-wire binary formats are more efficient to
> process in some absolute sense, but they're hardly free: you need to
> consider byte endianness for integers and flo
On 09/30/2014 01:09 PM, Shay Rojansky wrote:
> The idea of using extended query protocol for non-prepared queries
> raised another "best practices" question, which I'm hoping you can help
> with. To get rid of text encoding (which is locale-dependent,
> inefficient etc.) for certain fields, it see
At 2014-09-30 07:09:38 +0200, r...@roji.org wrote:
>
> the unknown type would be transferred as text and we'd provide that
> text to the user as an unprocessed string. Going full binary seems to
> eliminate this possibility.
If you're willing to hand the user an unprocessed string, why can't that
Shay Rojansky writes:
> The idea of using extended query protocol for non-prepared queries raised
> another "best practices" question, which I'm hoping you can help with. To
> get rid of text encoding (which is locale-dependent, inefficient etc.) for
> certain fields, it seems that we have to get
Hi again, a few days ago I sent a question (below) about using the extended
query protocol efficiently (especially for non-prepared statements). Your
responses spawned a good discussion between the npgsql developers, it's
here if you wish to look/weigh in:
https://github.com/npgsql/npgsql/issues/37
