From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Peter Mount <petermount(at)it(dot)maidstone(dot)gov(dot)uk> |
Cc: | "'Thomas Lockhart'" <lockhart(at)alumni(dot)caltech(dot)edu>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'The Hermit Hacker'" <scrappy(at)hub(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] 6.6 release |
Date: | 1999-12-13 10:38:45 |
Message-ID: | 3854CCB5.2C0DFAE3@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Meskes | 1999-12-13 10:57:23 | Datatype MONEY |
Previous Message | Hiroshi Inoue | 1999-12-13 09:42:01 | RE: [HACKERS] LONG |