On 23 February 2011 04:36, Greg Stark gsst...@mit.edu wrote:
This is only true for server encodings. In a client library I think
you lose on this and do have to deal with it. I'm not sure what client
encodings we do support that aren't ascii-supersets though, it's
possible none of them
On 02/23/2011 10:09 AM, Peter Geoghegan wrote:
On 23 February 2011 04:36, Greg Starkgsst...@mit.edu wrote:
This is only true for server encodings. In a client library I think
you lose on this and do have to deal with it. I'm not sure what client
encodings we do support that aren't
On 23.02.2011 17:16, Andrew Dunstan wrote:
On 02/23/2011 10:09 AM, Peter Geoghegan wrote:
On 23 February 2011 04:36, Greg Starkgsst...@mit.edu wrote:
This is only true for server encodings. In a client library I think
you lose on this and do have to deal with it. I'm not sure what client
On Wed, Feb 23, 2011 at 3:16 PM, Andrew Dunstan and...@dunslane.net wrote:
On 02/23/2011 10:09 AM, Peter Geoghegan wrote:
On 23 February 2011 04:36, Greg Starkgsst...@mit.edu wrote:
This is only true for server encodings. In a client library I think
you lose on this and do have to deal with
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 23.02.2011 17:16, Andrew Dunstan wrote:
On 02/23/2011 10:09 AM, Peter Geoghegan wrote:
I'm pretty sure all of the client encodings Tatsuo mentions are ASCII
supersets.
They are not. It's precisely because they are not that
On Tue, Feb 22, 2011 at 10:16 PM, Peter Geoghegan
peter.geoghega...@gmail.com wrote:
I'm investigating the possibility of developing a utility function for
our C++ client library, libpqxx, that produces array literals that can
be used in prepared statements. This problem appears to be a bit of
On 02/23/2011 10:22 AM, Heikki Linnakangas wrote:
On 23.02.2011 17:16, Andrew Dunstan wrote:
On 02/23/2011 10:09 AM, Peter Geoghegan wrote:
On 23 February 2011 04:36, Greg Starkgsst...@mit.edu wrote:
This is only true for server encodings. In a client library I think
you lose on this and do
On Wed, Feb 23, 2011 at 09:34:06AM -0600, Merlin Moncure wrote:
On Tue, Feb 22, 2011 at 10:16 PM, Peter Geoghegan
peter.geoghega...@gmail.com wrote:
I'm investigating the possibility of developing a utility function for
our C++ client library, libpqxx, that produces array literals that can
On 02/23/2011 10:40 AM, Kenneth Marshall wrote:
Can someone please point me in the direction of an established client
library/driver where all corner cases are covered, or at least enough
of them to produce a net gain in usefulness? There may well be
additional subtleties that have not
Binary mode had serious limitations, such as portability.
What are the other limitations?
As far as portability is concerned, we are using it on many different
operating systems and architectures without issue. Even our most recent
bump to 9.0.1 and 9.0.3 was flawless in regard to
On 23 February 2011 15:34, Merlin Moncure mmonc...@gmail.com wrote:
You can send nested arrays safely. You just have to be very formal
about escaping *everything* both as you get it and as it goes into the
container. This is what postgres does on the backend as it sends
arrays out the door
On 2/23/2011 3:06 PM, Peter Geoghegan wrote:
On 23 February 2011 15:34, Merlin Moncuremmonc...@gmail.com wrote:
You can send nested arrays safely. You just have to be very formal
about escaping *everything* both as you get it and as it goes into the
container. This is what postgres does on
On 02/23/2011 02:21 PM, Andrew Chernow wrote:
Binary mode had serious limitations, such as portability.
What are the other limitations?
As far as portability is concerned, we are using it on many different
operating systems and architectures without issue. Even our most
recent bump to
On Wed, Feb 23, 2011 at 03:34:45PM -0500, Andrew Chernow wrote:
On 2/23/2011 3:06 PM, Peter Geoghegan wrote:
On 23 February 2011 15:34, Merlin Moncuremmonc...@gmail.com wrote:
You can send nested arrays safely. You just have to be very formal
about escaping *everything* both as you get it
It's probably fine if you can control both ends. But there is no
guarantee of portability, nor does it seem likely to me there ever will
be, so I don't find your assertion terribly useful. The fact that it
hasn't broken for you doesn't mean it can't or won't be.
All true. If you change
I'm investigating the possibility of developing a utility function for
our C++ client library, libpqxx, that produces array literals that can
be used in prepared statements. This problem appears to be a bit of a
tar pit, so I'm hoping that someone can help me out. My goal is to
produce a template
On Wed, Feb 23, 2011 at 4:16 AM, Peter Geoghegan
peter.geoghega...@gmail.com wrote:
Since Postgres only supports encodings that are ASCII supersets, I
don't believe that I have to consider encoding - only my clients do.
This is only true for server encodings. In a client library I think
you
This is only true for server encodings. In a client library I think
you lose on this and do have to deal with it. I'm not sure what client
encodings we do support that aren't ascii-supersets though, it's
possible none of them generate quote characters this way.
We have a clear definition what
18 matches
Mail list logo
