Thread: 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