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

Re: PgAccess directory structure

From: "C(dot) Maj" <cmaj(at)freedomcorpse(dot)info>
To: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: PgAccess directory structure
Date: 2002-05-13 16:21:47
Message-ID: Pine.LNX.4.44.0205131154240.3055-100000@freebird.stanley.cup (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
On Sun, 12 May 2002, Nigel J. Andrews wrote:

> 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.

I agree completely here on the ifs.  My understanding is that the most
drastic changes will be coming with the schema changes in 7.3, so we
will need to consider that.

> > 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.

I don't think pgaccess supports multiple connections at the moment.
Could in the future I suppose.

> 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.

Well this is a true statement if you forget about the people using
pgaccess on windows.  They have to download separate dlls not available
on the postgresql site, AFAIK.  But this is a pretty trivial point.

> 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 think I kind of understand this.  It seems almost like something that
would be a benefit to any interface of postgresql.  Could it be
incorporated into pgtcl?  Instead of just a broad pg_select call how
about, in this case, pg_get_columns?  I've only really taken a look at
pgtcl so that is what I can comment on.



fingerprint 5EB8 2035 F07B 3B09 5A31  7C09 196F 4126 C005 1F6A

In response to

pgsql-interfaces by date

Next:From: Ross J. ReedstromDate: 2002-05-13 16:41:01
Subject: Re: Composite datatypes, dynamic member fields
Previous:From: C. MajDate: 2002-05-13 15:49:51
Subject: Re: pgaccess - the discussion is over

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