Обсуждение: PgAccess directory structure

I'm not sure how far along the plans for pgaccess are. However,I like to
propose some changes to the directory structure. I would be looking
to have these changes implemented in the main postgres tree if the new
repository isn't operational at the time, as long as that tree is used to
initialise the new repository.


Reason for change (as I see it):

The view seems to be that PgAccess is treated as a separate entity to the main
postgres system. This is a good idea as it enables features to be added without
being tied to a specific version of the backend, amongst other
reasons. However, there is a problem in this in that some parts of PgAccess are
required to be version specific and therefore a single installation of the GUI
can not be used with backends of different version safely. Therefore, older
database users can not gain access to new features unless those are added as
patches to previous releases.

An example is that of the use of views in the reports module. At some stage it
became possible to determine the columns in views and therefore possible to use
them in reports. Obviously prior to that point views were unusable in that
module and so Teo hadn't included them as possible data sources. Adding this
feature now would cause problems when used with for older databases. Although
a defensive ploy here is easy to see I think a better, more flexible scheme is
possible.


Proposal:

That the lib directory gain one level of subdirectories called
Pg<postgres-version>, that code specific to backend version be placed in these
directories and that version independent code by kept in the lib directory.

The backend is interrogated for it's version on the first database connection
and code loaded ondemand from lib/Pg<newest-not-exceeding-interrogated> to
lib/Pg<oldest> and then from lib, with loading stopping at the first file
satisfying the demanded code.

So for example: the Reports namespace (module) would be requested by the line
Reports::build $parent

and the files required to satisfy that code request would be searched for in
the order:
lib/Pg7.3devel/reports.tcllib/Pg7.3/reports.tcllib/Pg7.2.1/reports.tcllib/Pg7.2/reports.tcllib/reports.tcl

Now, it can be seen that if there is any backend version specific code for the
reports module then the nonversion specific code will not be loaded. This is
obviously a bad idea.

One of the ways around this is to note that the existing code loads all the
modules at startup and to do something similar. Given a module name on startup
that module's code can be loaded by calling:<module-name>::Init
where Init may or may not do anything useful apart from causing the code to
load. Backend version specific Init procs would force the load of the common
code for the module by calling:<module-name>::CommonInit
.

An alternative is to do as I have done today and use a convience routine that
loads the common code, via the CommonInit call, and then the version specific
code, via the Init call. This method, although losing the ability to let the
module decide when the common code should be loaded initialised does enable
version specific code to replace and generally override the common code as
needed.

There is a third possible solution using version specific code in a separate
namespace (presumably a subnamespace) to that of the common module code but I
can see some awkwardness with that method and I'm generally less enamoured with
it. Having said that it'd not be too difficult to populate an array providing
version specific name lookup from an unversioned name.

I prefer the second of these schemes, but then I've already coded that so I
could be seen as biased. I would also go ahead a submit these changes for
inclusion in the main postgres tree if I was confident that this wouldn't cause
problems to others currently applying or waiting to apply patches on top of
which this could be seen as a significant change in structure on disk and
therefore really should be done after agreement has bee obtained.

On the subject of pending patches, if this rearrangement were to be
implementated I should imagine that it would be best done after other people's
patches have been applied since there would probably be more work involved in
changing those patches to use this scheme than for this scheme to be placed
into the patched tree. However, this or some other decided upon scheme should
be done _before_ any work goes into producing code that uses features of 7.3,
unless that code is generic enough to work on any version of the
backend. Therefore, I think agreement needs to be reached pretty quickly.


-- 
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants

<operational note: I hope all the pgaccess people have subscribed to
INTERFACES by now. If any non-pgaccess people start to complain that
we've taken over the group, just holler: we can get our own list, then>

On Sat, May 11, 2002 at 05:50:52PM +0100, Nigel J. Andrews wrote:
> 
> 
> I'm not sure how far along the plans for pgaccess are. However,I like to
> propose some changes to the directory structure. I would be looking
> to have these changes implemented in the main postgres tree if the new
> repository isn't operational at the time, as long as that tree is used to
> initialise the new repository.
> 

Note that the core pgsql developers seem willing to let us actually apply
patches to the REL_7_2 branch, so it may be possible to do all this in place.

> Proposal:
<proposal on how to make pgaccess version agnostic, and backward compatible>

I agree with the general idea of this proposal: the implementation sounds
o.k., but I haven't been that deep in the code recently. Having the latest
and greatest pgaccess handle various backends sounds like a great idea.

Ross

> -----Original Message-----
> From: Ross J. Reedstrom [mailto:reedstrm@rice.edu]
> Sent: 11 May 2002 20:03
> To: pgsql-interfaces@postgresql.org
> Subject: Re: [INTERFACES] PgAccess directory structure
>
>
> <operational note: I hope all the pgaccess people have
> subscribed to INTERFACES by now. If any non-pgaccess people
> start to complain that we've taken over the group, just
> holler: we can get our own list, then>
>
> On Sat, May 11, 2002 at 05:50:52PM +0100, Nigel J. Andrews wrote:
> >
> >
> > I'm not sure how far along the plans for pgaccess are.
> However,I like
> > to propose some changes to the directory structure. I would
> be looking
> > to have these changes implemented in the main postgres tree
> if the new
> > repository isn't operational at the time, as long as that
> tree is used
> > to initialise the new repository.
> >
>
> Note that the core pgsql developers seem willing to let us
> actually apply patches to the REL_7_2 branch, so it may be
> possible to do all this in place.
>
> > Proposal:
> <proposal on how to make pgaccess version agnostic, and
> backward compatible>
>
> I agree with the general idea of this proposal: the
> implementation sounds o.k., but I haven't been that deep in
> the code recently. Having the latest and greatest pgaccess
> handle various backends sounds like a great idea.

Much as this sounds good, I find this to be the single biggest headache
with development of pgAdmin. pgAccess has an advantage over pgAdmin in
that it is shipped with PostgreSQL - my advice to you would be to take
advantage of this & go version-specific and spend time making great
software rather than figuring out (for example) how to support 7.3 &
<7.3 versions of pg_aggregate.

Hmm, advice to the competition. I think I need a beer now :-)

Regards, Dave.

Nigel J. Andrews writes:

> That the lib directory gain one level of subdirectories called
> Pg<postgres-version>, that code specific to backend version be placed in these
> directories and that version independent code by kept in the lib directory.

Other tools that try to handle more than one version usually just do a

if (backend_version < 7.2) do this;
else do that;

(examples: JDBC, ODBC, pg_dump).  (Even if "do this" would be empty, you
can print a message or something.)

Keeping a separate file for each version may lead to a lot of duplicate
code being necessary and hard to maintain.  (All the module-loading stuff
you mentioned makes my head spin, but I can understand an "if" statement
like the above. ;-) )

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.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.
        regards, tom lane

On Sun, 12 May 2002, Tom Lane wrote:

> Peter Eisentraut <peter_e@gmx.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

On Sun, 12 May 2002, Nigel J. Andrews wrote:

> On Sun, 12 May 2002, Tom Lane wrote:
>
> > Peter Eisentraut <peter_e@gmx.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