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 the
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 Moncure 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 go
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 2/23/2011 3:06 PM, Peter Geoghegan wrote:
On 23 February 2011 15:34, Merlin Moncure 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 se
On 23 February 2011 15:34, Merlin Moncure 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 in text. It mig
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 libpq/l
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 occurr
On Wed, Feb 23, 2011 at 09:34:06AM -0600, Merlin Moncure wrote:
> On Tue, Feb 22, 2011 at 10:16 PM, Peter Geoghegan
> 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
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 Stark wrote:
This is only true for server encodings. In a client library I think
you lose on this and do have to deal wi
On Tue, Feb 22, 2011 at 10:16 PM, Peter Geoghegan
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 a
> tar pit, so I'm hopin
Heikki Linnakangas 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 they are not
>> allowed as s
On Wed, Feb 23, 2011 at 3:16 PM, Andrew Dunstan wrote:
> On 02/23/2011 10:09 AM, Peter Geoghegan wrote:
>>
>> On 23 February 2011 04:36, Greg Stark 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 wha
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 Stark 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 suppo
On 02/23/2011 10:09 AM, Peter Geoghegan wrote:
On 23 February 2011 04:36, Greg Stark 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
On 23 February 2011 04:36, Greg Stark 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 generate quote char
> 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 w
On Wed, Feb 23, 2011 at 4:16 AM, Peter Geoghegan
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 lose on this and do have to
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 f
18 matches
Mail list logo
