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

Re: ALTER VIEW

From: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
To: "'jm(dot)poure(at)freesurf(dot)fr'" <jm(dot)poure(at)freesurf(dot)fr>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: ALTER VIEW
Date: 2002-02-23 21:12:33
Message-ID: FED2B709E3270E4B903EB0175A49BCB10475EE@dogbert.vale-housing.co.uk (view raw or flat)
Thread:
Lists: pgadmin-hackers

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm(dot)poure(at)freesurf(dot)fr] 
> Sent: 23 February 2002 18:30
> To: Dave Page
> Cc: pgadmin-hackers(at)postgresql(dot)org
> Subject: Re: [pgadmin-hackers] ALTER VIEW
> 
> 
> 
> > 4) A class library such as this should _never_ display any user 
> > interface. That is the job of the application.
> I agree. Could you outline the code, please?

Dunno, all the other code just lets errors from the backend trickle up.

> > 5) The modifications to the SQL property are messy & mainly 
> > unnecessary (certainly with #1 above - that just needs bDrop & 
> > szViewName).
> 
> On the converse, I think it is a very powerfull way to write 
> SQL code. 
> Actually, I was going to ask you to apply this kind of 
> modification to all 
> SQL clauses in pgSchema.
> 
> SQL (bDrop, bCreate, bACL, bComment, ....) is quite 
> straightforward. In the 
> future, we could ask a distinct object to build SQL queries, 
> with batch 
> processing and transactions. 

Yes, these are fine, but add them when we need them, not just for the sake
of it and don't try to modify comments and definitions in this way. If you
do, with complex object you will end up with arguments lists that are far
too long. For a simple object like a view, I think you had got up to about 8
arguments.

> 
> Also, I would like to point out there should not be any SQL 
> code in Views, 
> Tables, etc.. All should be performed at object level in 
> pgViews, pgTables

Then pgSchema will not work at all. You cannot build a collection of object
if all the code is in the objects.

> > 7) The Comment cache is not being invalidated.
> Why should I invalidate comment cache? The fake view was created with 
> comments and acl. Do I miss something?

The entry in the cache will be for the old view oid - there will be none for
the new view. You must invalidate the cache so it is repopulated with up to
date data the next time *any* comment is accessed.

> B. Triggers
> The new code allows to move a trigger from one table to 
> another. How can I 
> refresh display after modification?

Don't know, never done it. You might want to check out how we update object
names at present though - that'll show how we locate the relevant node.

> By the way, should I CC you or not? pgadmin_hackers is 
> sometimes too slow for discussion.

Marc did some work on the server (Wednesday?) that sped things up no end. I
get both copies pretty much together now, so no CC is necessary. If we need
to actually chat, then we can always use ICQ or something.

Regards, Dave.

pgadmin-hackers by date

Next:From: Jean-Michel POUREDate: 2002-02-23 21:42:28
Subject: Re: Schema unique stamp (OID, MD5?)
Previous:From: Dave PageDate: 2002-02-23 20:53:09
Subject: Re: Schema unique stamp (OID, MD5?)

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