Re: PgAccess directory structure

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.

--Chris

--

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