Sender: tgl@mythos.jpl.nasa.gov
Message-ID: <361A4B76.A4F9C656@alumni.caltech.edu>
Date: Tue, 06 Oct 1998 16:55:18 +0000
From: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Organization: Caltech/JPL
MIME-Version: 1.0
To: Gerald Gryschuk <ggryschuk@scf.sk.ca>
CC: Postgres Interfaces Mailing List <pgsql-interfaces@postgresql.org>
Subject: Re: [INTERFACES] Re: ... and here's another change.
References: <361986E4.4E0FFB18@home.com> <36199CF2.93870EE@alumni.caltech.edu>
	<3619D3E5.F8F95715@home.com> <361A1C99.786376D0@alumni.caltech.edu>
	<361A3D97.209643C@scf.sk.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

(topic: standalone configuration of psqlodbc vs Postgres tree config)

> I don't want to sound harsh but you do realize this significantly
> reduces the flexibility we have to update just the odbc driver?

No, it's good to make sure we are covering all the points. Yes, I
realize all (?) of the implications here. I don't see this as reducing
flexibility; imho it gives us more of it, since we can have the
standalone distribution evolve, then snapshot it into the Postgres tree
when desired. For example, the Postgres tree didn't have v6.30.0250,
even though it has been available for a while. Of course, I've got an
obligation to make the "integrated distribution" work correctly, and to
make sure it doesn't stomp on the "standalone distribution" which to be
clear consist of the same set of source code as the integrated one.

I'm also trying to look out for overall Postgres issues:

1) there are no other "independent configures" in the tree (yet).
2) Postgres has no experience (yet) with long-term support for ODBC
under Unix.
3) there is an upcoming v6.4 release, needing a workable integration
now.
4) you have indicated that you are reaching your time limits on this,
and we didn't yet have a tree which completely works. I've also dumped
some time into this, and I'm running out of it too (I'm pushing 20-30
hours of work per week on Postgres at the moment :). We're all motivated
to get this stuff working, and it's time to have a firm starting point.
5) we get configure support "for free" in the main distribution. The
standalone configure is on your/our shoulders entirely. So if we have
support for ODBC in the main configure, then our standalone support can
just tag along, with us occasionally needing to push something up into
the main configure, maybe.
6) I've fixed one or two problems in the main configure at the same
time, so Postgres overall will benefit from this exercise.
7) things can be adjusted once we have a solid starting point. When we
have that, then things can evolve. For example, our main configure gurus
may have opinions on standalone vs integrated, and will be happy to have
the "independent configure". We now have something they can play with.

> Given that the odbc driver has many more ports, and therefore changes,
> to be made before it catches up with the distribution I suspect there
> may still be a few changes necessary in the configure files. It would
> be nice if this could be updated independently of the distribution
> itself.

It can. The standalone configure should still work. I'm working out some
final details in the src/configure & odbc/configure integration, but it
looks like it is coming together nicely. Wait a few hours for me to
commit another round of configure/makefile changes into the cvs tree
before looking closely at it; it doesn't quite work with the large blob
of changes I committed last night.

Do you have access to the cvs tree, or should I send you a tarball? btw,
we'll need to start exchanging patch files rather than these full
tarballs now that we have the Postgres tree for a reference.

Talk to you soon...

                     - Tom