Re: ALTER VIEW

Hi Dave,

I commited some changes to CVS. Now, I need more info to understand :

A. VIEWS
> 1) Don't create the view twice, create the fake one then rename it - it's
> less expensive and avoids the potential for the second create to fail.
Done.

> 2) The szOldDefintion stuff can now be removed.
Done

> 3) The OID and Definition could be retrieved in one operation rather than
> 2.
Done

> 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?

> 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. This would be very powerfull and would allow the
querying of MySQL, MSsql server, etc... OK, let's not go so far, I am a
day-dreamer.

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,
pg** using ***precisely the new SQL clause. The less SQL we write by hand,
the easier we will maintain pgAdmin2.

> 6) The iLogEvent "Entering..." code should be immediately after the On
> Error code, not in the middle of the function.
Done

> 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?

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

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

Cheers,
Jean-Michel