Skip site navigation (1) Skip section navigation (2)

Re: PgAccess directory structure

From: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>,pgsql-interfaces(at)postgresql(dot)org
Subject: Re: PgAccess directory structure
Date: 2002-05-12 20:06:21
Message-ID: Pine.LNX.4.21.0205122054190.2451-100000@ponder.fairway2k.co.uk (view raw or flat)
Thread:
Lists: pgsql-interfaces
On Sun, 12 May 2002, Tom Lane wrote:

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Keeping a separate file for each version may lead to a lot of duplicate
> > code being necessary and hard to maintain.
> 
> Peter has a good point: you'll almost certainly end up with lots of
> duplicate code to maintain if you try to split at the file level.
> "If"s seem to work well enough in pg_dump.
> 
> Another potential objection to the scheme as you proposed it is that
> any given instance of pgaccess could only talk to one backend version.
> I dunno whether pgaccess supports multiple connections now or might
> do so in the future --- but if that's of interest, adapting to backend
> version on-the-fly is a lot better than loading different versions of
> support code at startup.

It's a fair comment. In deed when I was going to add views to the reports
sources I was only planning to do a test on backend version. Then I decided
that pgaccess was part of postgres and therefore not a separate entity and so
even that was unnecessary. Also in that instance it's even possible to
determine the required backend support by testing for the required
functionality with no version test at all.

Also a fair point about the multiple connections. I haven't done the code yet
but unloading and reloading the correct code files on a change in version was
next on my investigation/do list.

I must say though that viewing different versions as providing different
facilities means that there should be an interface layer to those different
facilities. I'm not explaining this very well but if getting column names for a
table involved different queries shouldn't that part of the interface be split
out into an interface layer? Think in terms of a different database, would you
suggest using if mysql then ... elseif postgres then ... endif?

I don't really care whatever way the concensus goes. It was an idea for
supporting different versions in a flexible manner.  I've got the version being
placed into a global already so either way it's possible to start adding stuff
for 7.3 whether or not it conflicts with older backends.


-- 
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants


In response to

Responses

pgsql-interfaces by date

Next:From: maxim lapeineDate: 2002-05-13 07:01:01
Subject:
Previous:From: Tom LaneDate: 2002-05-12 15:52:09
Subject: Re: PgAccess directory structure

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group