Skip site navigation (1) Skip section navigation (2)


From: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
To: "'Jean-Michel POURE'" <jm(dot)poure(at)freesurf(dot)fr>
Cc: pgadmin-hackers(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: DROP/CREATE
Date: 2001-10-30 10:02:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackerspgsql-hackers

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm(dot)poure(at)freesurf(dot)fr] 
> Sent: 30 October 2001 09:21
> To: Dave Page
> Cc: pgadmin-hackers(at)postgresql(dot)org
> Subject: RE: DROP/CREATE
> What if that 
> >function takes an entire tuple from a
> >(modified) table as an argument (or returns it) - then 
> things get really
> >hairy.
> >
> >I think the only way we can reliably do this is with the addition of 
> >either safe CREATE OR REPLACE sql commands, or addition of a 
> suitable 
> >pg_dependencies table which is maintained by PostgreSQL itself.
> A third solution would be to work with PL/pgSQL and 
> development tables (i.e 
> code repository).
> The notion of Code repository is interesting because it is 
> not linked to 
> PostgreSQL internals.
> A code repository can be located anywhere on the planet. Cool 
> feature for 
> development teams.

Yes (and I agree that it would be a good feature), but that will still
require full client side parsing of the code to figure out the dependencies
- I for one, do not wish to try to recreate (and keep up-to-date) the
PostgreSQL parser in VB. Besides which, if we take it that far then we might
just as well use reverse engineered SQL to scan for dependencies. I know you
don't like reverse engineered code, but bear in mind that the important bits
are reported directly from PostgreSQL (e.g. pg_proc.prosrc).

> With PL/pgSQL we can ***easily*** track and rebuild objects. 
> Before that, 
> we need a PL/pgSQL wizard in pgAdmin.
> PostgreSQL might incorporate PL/pgSQL as a standard feature 
> when protection 
> for infinite loops is added.

I think that's unlikely from the responses you got from pgsql-hackers
> Code repositories would be a nice solution as completely 
> independent from 
> PgAdmin. This means PhpPgAdmin would also benefit from it. 
> Ultimately, when 
> Postgresql gets PL/pgSQL infinite loop protection, 
> repositories could get 
> included in Postgresql. So why not go for it?

I've no problem with working with the phpPgAdmin people, that can only be a
good thing.

> > > I am going to have a look at updating views within a single 
> > > transaction. Are there special guidelines for compiling phSchema?
> >
> >No, just that if you break compatibility you may need to run 
> >buildall.bat(?) to recompile everything. Please don't commit 
> anything 
> >to do with this until I've taken a look either - I don't want to add 
> >any more features now until after the first full release.
> OK, I will not upload pgSchema to CVS if modified. On my 
> side, I have to 
> consider migration from pgAdmin I to pgAdmin II to comply 
> with PostgreSQL 
> 7.2. Without rebuilding, I cannot work and maintain 100 
> tables, 50 views, 
> 30 triggers and 200 functions.

No, I can see your problem. Remember though that the code in pgAdmin I is
far from foolproof, as you've said before, we need absolute confidence that
*every* dependency is found and dealt with, something the pgAdmin I code
makes a good stab at but could be fooled.

I really believe that the only truly reliable way to do this is for
PostgreSQL to provide either a pg_dependencies table or a function that
tells us the dependencies for a given object. If this email actually makes
it to the pgsql-hackers list perhaps someone can comment on whether this is
likely to happen?

> What are your plans? If you don't mind, I would prefer to go 
> for a PL/pgSQL 
> repository feature. This would be more advanced that in 
> pgAdmin I, testing 
> the new features on my side only. Please advise me for 
> pgShema compilation 
> guidelines.

I'm happy for you to look at code repositories, though I think they should
allow use of PL/Perl and PL/TCL as well. This shouldn't be a problem of
course because the PL code isn't 'compiled' by PostgreSQL like SQL functions
or Views are.

As far as pgSchema goes, compile it as I said, but pay attention to the
existing design and try to match the style/layout of the classes. For an
example of 'bolted on' functionality (as opposed to the core object
hierarchy), look at the History/Graveyard stuff.

Cheers, Dave.

pgsql-hackers by date

Next:From: Jean-Michel POUREDate: 2001-10-30 10:17:51
Subject: Re: [HACKERS] Serious performance problem
Previous:From: Tille, AndreasDate: 2001-10-30 09:59:10
Subject: Re: Serious performance problem

pgadmin-hackers by date

Next:From: Jean-Michel POUREDate: 2001-10-30 10:38:48
Subject: Re: DROP/CREATE
Previous:From: Jean-Michel POUREDate: 2001-10-30 09:20:35
Subject: Re: DROP/CREATE

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group