Re: [HACKERS] contribute pg_get_viewdef2 et al - Mailing list pgadmin-hackers
From | Dave Page |
---|---|
Subject | Re: [HACKERS] contribute pg_get_viewdef2 et al |
Date | |
Msg-id | 03AF4E498C591348A42FC93DEA9661B83AF071@mail.vale-housing.co.uk Whole thread Raw |
Responses |
contribute pg_get_viewdef2 et al
(Andreas Pflug <Andreas.Pflug@web.de>)
|
List | pgadmin-hackers |
[moved back on the appropriate list] Hi Andreas, > -----Original Message----- > From: Andreas Pflug [mailto:Andreas.Pflug@web.de] > Sent: 06 May 2003 18:21 > To: Dave Page > Subject: Re: [HACKERS] contribute pg_get_viewdef2 et al > > > Hi Dave, > > >pgAdmin will not use these versions unless they become part > of the main > >PostgreSQL distribution. I've spent too long in the past maintaining > >code that tried to use non-standard features, and additional > >code/objects in the backend and decided back when designing > pgAdmin II > >that we won't get sucked down that path again. > > > I don't quite understand your point. pgadmin3 is aware of > what's in the > database. For example, WITH GRANT OPTION is enabled only if > the backend > is 7.4 or up. Same with retrieving the definitions: > pg_catalog.pg_get_viewdef2 will be used if present, and > pg_get_viewdef > if not; After a couple of releases of PostgreSQL you will start to see why a bit more clearly :-) Basically, things tend to get far more messy with every release because things in the database get moved around, new catalogues are added and old ones deprecated etc. In pgAdmin I, we used to make extensive use of functions and views on the server. They became an absolute nightmare to maintain requiring increasingly complex code to check and recreate them as required because we could never be sure that a user would upgrade/reinstall them following a server upgrade, or that they hadn't fiddled with them. Of course, that's ignoring the fact that each part of the system that could use alternate code got increasingly more complex, and you still ended up writing to the lowest common denominator anyway. > At the moment, I feel that /contrib is the maximum that Tom > will accept, > having 7.4 release date coming nearer. I had a conversation > about this > with Tom, proposing to modify the existing ruleutil.c in a defensive > manner (if unknown whether parentheses are needed, use them), but he > didn't even agree on simple rules for parenthese usage for JOINs. Tom is being cautious and to be honest I'm on his side on this one. If a release goes out including functions used in the dumping of databases that do not work quite as they should because a few parentheses are missing, that'll be a major blot in PostgreSQL's reputation and is bound to spark up debate in places like /. where the MySQL fans will finally have something negative to say about PostgreSQL that is actually valid. I would suggest submitting your functions as patches to the backend that do all the reformatting but do not mess with the parentheses. I suspect this is the only way you'll get the code into either the main system or /contrib. Nobody seemed averse to that idea when I mentioned it on the list a while ago. Regards, Dave.
pgadmin-hackers by date: