Alex Peshkov escreveu:

> Hmmm...
> Looks like that it means that procedure (and any other object in use) can
> never be modified from other connection / transaction? If I'm not mistaken
> with it, too many users will start crying 'regresion!!!' after this change.
> Specially when we provide connection/transaction independent cache of
> prepared statements.
>
> Remember, we had to re-enable modification of procedure in use in next support
> release version after it was disabled? I do not want to step on it once more.
> ........
>

That's true, but it's why I proposed MON$ extensions.

Anyway, my work didn't progressed too much on the missing parts (cyclic
dependencies and multiple DDL in the same transaction). I'm now
experiment changing procedure DDL logic to DdlNodes, changing system
tables before start DSQL compilation.

And then I need to insist on isc_ddl deprecation (remove it in V3.0).
Changing DDL logic to DdlNodes (making parser OO-friendly and DDL
changes much more simple) is not very difficult, but construct parser
nodes from DYN codes seems very difficult task. Maintain parallel DYN
handling is also far from ideal.

To not make the (few) users doing DDL changes with GPRE very unhappy, we
may introduce EXECUTE STATEMENT in GPRE. What you think?

>> Thoughts?
>>
>
> Another idea, how to make metadata cacge work better. Imagine that we have
> versions of the objects in the cache. A correct version of the object is
> searched for according to VIO rules. This can let us have full support of
> transactions in DSQL and not limit users with modification of only unused
> objects. I.e. when object is modified, previous version of it remains
> available for all transactions, started before it's committed.
>
> Certainly, it seems to be harder to implement compared with your suggestion.
> But I think it will provide us a lot of benefits in the future.

I think it's very hard to implement, is not generally desired
functionality, and not work in some conditions.

When you have table changes, versions doesn't apply. Why one wants to
update an already dropped column?

When one founds a bug in a procedure, he fixes it and the fix may need
data changes (caused by previously bugged code). Maintaining others
running obsolete code may be a very bad thing.


Adriano