Thread: RE: [HACKERS] 6.6 release

-----Original Message-----
From: Thomas Lockhart [mailto:lockhart@alumni.caltech.edu]
Sent: Friday, December 10, 1999 3:44 PM
To: Peter Mount
Cc: 'Tom Lane'; 'The Hermit Hacker'; Bruce Momjian;
PostgreSQL-development
Subject: Re: [HACKERS] 6.6 release


> > I'm also confused. So far, I've been working on the premise that the
> > next release would be 7.0 because of the probably major additions
> > expected, and that I'm hitting the JDBC driver hard to get as much
of
> > the 2.0 spec complete as is possible.

OK, now *I'm* confused too! Peter, what in your stuff *requires* a
version renumbering to 7.0? The proposal was that we consolidate
changes in the backend server for a 6.6 release. Why does JDBC need to
wait for a "7.0" in the version number to support the 2.0 spec?

PM: Nothing yet, but it's possible that when I start on Arrays it will
need to work with the latest backend. Also, the version currently in CVS
(originally intended for 6.5.3) is the first not to be backward
compatible with earlier backends, and this one may follow suit.

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 was what I was thinking also, until yesterday.  I think that the
> proposal on the table is simply to consolidate/debug what we've
already
> done and push it out the door.  If you've still got substantial work
> left to finish JDBC 2.0, then it'd be better left for the next
release.

Right.

PM: That's exactly what I'm planning. There is a lot of work to get it
up to spec, so if we have a 6.6 in Feb. then I won't have it all done by
then.

> I know I have a lot of little loose ends dangling on stuff that's
> already "done", and a long list of nitty little bugs to fix, so it
> makes sense to me to spend some time in fix-bugs-and-make-a-release
> mode before going back into long-haul-feature-development mode.
> Now, if other people don't have that feeling, maybe the idea of
> a near-term release isn't so hot after all.

Yes I've got that feeling too!! :)

PM: I'm thinking that now (after thinking about it over the weekend that
is)
-- 
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

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