Re: [HACKERS] 6.6 release - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: [HACKERS] 6.6 release
Date
Msg-id 3854CCB5.2C0DFAE3@tm.ee
Whole thread Raw
In response to RE: [HACKERS] 6.6 release  (Peter Mount <petermount@it.maidstone.gov.uk>)
List pgsql-hackers
Peter Mount wrote:
> 
> PM: As for the 2.0 spec, we currently only touch the surface, and there
> may be the possibility that I have to add some functionality in the
> backend, esp. with PreparedStatement or CallableStatement.

That would be rally great if some kind of PreparedStatement support would 
appear in backend. Currently all frontends that need it (at least ODBC, JDBC,
possibly others too) must fake it.

Also the protocol (or frontend) should be made smarter about how to insert 
Binary data, espacially in the light of the possibility that we will soon get
support for LONG fields thanks to Jan.

I would hate to construct an insert (or update) command by base64 encoding a
large word file and then constructing an humongous string of it by appending
"insert into t(contents) values('" and prepending "');"

I would much prefer the intelligence for it to be in at least libpq if not 
in the protocol, so that I could use something like:

s = prepare("insert into t(contents) values($1);
s.bind(open(myfile).read(),'text');
s.execute()
s.bind(open(myotherfile).read(),'text');
s.execute()
s.close()

That would have the advantage of possibly not encoding the whole thing but 
even possibly compressing it for transfer in case of slow links.

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


pgsql-hackers by date:

Previous
From:
Date:
Subject: Warnung
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] libpq questions...when threads collide