Re: [HACKERS] contribute pg_get_viewdef2 et al

[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.