Re: Escaping strings for inclusion into SQL queries - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Escaping strings for inclusion into SQL queries
Date
Msg-id 3B8FB56D.74CAC792@tm.ee
Whole thread Raw
In response to Re: Escaping strings for inclusion into SQL queries  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Barry Lind wrote:
> 
> I agree with Hannu, that:
> 
>   * make SQL changes to allow PREPARE/EXECUTE in main session, not only
> in SPI

A more ambitious project would be 

* develop an ANSI standard SQL/CLI compatible postgreSQL client library, change wire protocol and SQL language as
needed;)
 

> is an important feature to expose out to the client.  My primary reason
> is a perfomance one.  Allowing the client to parse a SQL statement once
> and then supplying bind values for arguments and executing it multiple
> times can save a significant amount of server CPU, since the parsing and
> planning of the statement is only done once, even though multiple
> executions occur.  This functionality is available in the backend
> (through SPI) and plpgsql uses it, but there isn't anyway to take
> advantage of this SPI functionality on the client (i.e. jdbc, odbc, etc.)
> 
> I could see this implemented in different ways.  One, by adding new SQL
> commands to bind or execute an already open statement, or two, by
> changing the FE/BE protocol to allow the client to open, parse,
> describe, bind, execute and close a statement as separate actions that
> can be sent to the server in one or more requests.  (The latter is how
> Oracle does it).

The latter is also the ODBS and JDBC wiew of how it is done. The current 
PG drivers have to fake it all on client side. 

> 
> I also would like to see this added to the todo list.
> 

------------
Hannu


pgsql-hackers by date:

Previous
From: Barry Lind
Date:
Subject: Re: Escaping strings for inclusion into SQL queries
Next
From: Dave Blasby
Date:
Subject: Bad behaviour when inserting unspecified variable length datatypes