Re: PgAccess directory structure
От | Nigel J. Andrews |
---|---|
Тема | Re: PgAccess directory structure |
Дата | |
Msg-id | Pine.LNX.4.21.0205122054190.2451-100000@ponder.fairway2k.co.uk обсуждение исходный текст |
Ответ на | Re: PgAccess directory structure (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PgAccess directory structure
|
Список | pgsql-interfaces |
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
В списке pgsql-interfaces по дате отправления: