Skip site navigation (1) Skip section navigation (2)

Re: Correctly producing array literals for prepared statements

From: Andrew Chernow <ac(at)esilo(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Kenneth Marshall <ktm(at)rice(dot)edu>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Correctly producing array literals for prepared statements
Date: 2011-02-23 21:19:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> 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 protocol, libpqtypes needs to be adjusted. 
  I think that is a very fair statement.  It already toggles on server 
version around a few changes in the past ... like the money data type. 
So far, since 8.1, the number of changes to the binary protocol has put 
me to sleep :)

> The other downside I see is that binary protocols are often a lot harder
> to debug, but maybe that's just me.

Also very true.  However, libpqtypes addresses this by abstracting the 
end user from the binary transformation or preparation.  Instead, users 
are presented with a printf/scanf style interface.  PQexecf(conn, 
"select %int4 + %int4", 4, 4)  is pretty far removed from the underlying 
byte swapping, parallel array setup for PQexecParams and other 
nastiness.  But yes, the maintainer of the library must deal with 
protocol changes and provide backward compatibility.

Andrew Chernow
eSilo, LLC
global backup

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-02-23 21:20:54
Subject: Re: Binary in/out for aclitem
Previous:From: Kenneth MarshallDate: 2011-02-23 21:01:54
Subject: Re: Correctly producing array literals for preparedstatements

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group