Re: Pseudo modification of views and triggers (again) - Mailing list pgadmin-hackers
From | Dave Page |
---|---|
Subject | Re: Pseudo modification of views and triggers (again) |
Date | |
Msg-id | FED2B709E3270E4B903EB0175A49BCB10475BA@dogbert.vale-housing.co.uk Whole thread Raw |
In response to | Pseudo modification of views and triggers (again) (Jean-Michel POURE <jm.poure@freesurf.fr>) |
Responses |
Re: Pseudo modification of views and triggers (again)
|
List | pgadmin-hackers |
> -----Original Message----- > From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr] > Sent: 19 February 2002 19:53 > To: Dave Page > Cc: pgadmin-hackers@postgresql.org > Subject: Pseudo modification of views and triggers (again) > > > Dear Dave, > > 1) Views > View pseudo-modification works fine. It was implemented in > pgSchema->pgView->Let Defition property. This allows the > modification of > pgSchema->pgView->view > definition only (not the name of the view). The code looks great. I've made a couple of minor changes: - In pgSchema, I've added code to commit the change to the RCS. This was also missing from the Function modification code. - In pgAdmin.frmView:Initialise I've moved the code that unlocks the hbx. This is to be consistant with other similar functions. - In pgAdmin.frmView:cmdOK_Click I've removed the code that saved the comment before updating the definition. Just updating the comment first should do fine. > This is OK because view names should not be changed (views > can be called > inside functions or other views). I've just found out that views can be renamed using ALTER TABLE <viewname> RENAME... iirc, VIEWs are referred to by OID from PL/SQL functions & other views, and by name from pl/pgsql functions. Sequences can also be renamed in this way. It might be an idea if you warned the user that some things will break when the view is redefined in cmdOK_Click, and give them a chance to abort. > > The problem with pgSchema->pgView->Let Defition is that if a > wrong definition > is entered, an error is reported and the definition is saved > in PostgreSQL. > This ***might*** be a new feature of PostgreSQL 7.2. I don't > remember 7.1 > accepted wrong definitions for views, but I may be wrong. > > We need to rollback views in such a case. > > Does this means implementing view modification at > pgSchema->View level? 7.2: helpdesk=# create view cow as select widget from notable; ERROR: Relation "notable" does not exist ERROR: Relation "notable" does not exist helpdesk=# create view cow as select widget from pg_class; ERROR: Attribute 'widget' not found ERROR: Attribute 'widget' not found helpdesk=# create view cow as selects * from pg_class; ERROR: parser: parse error at or near "selects" ERROR: parser: parse error at or near "selects" helpdesk=# I would suggest (in pgSchema) saving the definition in a local variable before the update attempt, then if an error occurs, re-run the old SQL. NOTE: I also noticed that you do not retrieve the new OID. This could be done along with the definition. > 2) Triggers > It should be possible to change the name of a trigger as well as the > underlying function, but not the trigger table itself. > Therefore, it sounds > like trigger pseudo modification should be implemented in > pgSchema->Triggers. > What is your opinion? Triggers could be implemented exactly as Views. Each property will need to be handled seperately, though in the future we might look into merging multiple updates into one. The Name property must be handled differently (as it would be for Views & Sequences) in the Collection class. This has already been done for tables, so there is some example code to steal. Regards, Dave.
pgadmin-hackers by date: