No Parse execution and on the fly DDL change

There was an interesting question on PGDay17

“What is going on if we have a cursor cached on server side and suddenly (for the client) underlying DDL changed (added column, changed column type, etc. etc.).  I was claiming that an additional round trip would happened with re-parse request, but I was wrong!

I made an experiment and here is results:

“usual execution“: w/o DDL change for the underlying table,
That is an execution after cursor have been cached both on server and client side, actually I have not closed the cursor, but reused the same cursor:

DDL_chg1execution after DDL: I’ve added a single column to the underlying table:
It is the same cursor and the same round of execution as above, but I’ve just added a column.

DDL_chg2

You can see Oracle sends the same packet as after 1st execution and  parsing so client aware of a new column.

For just in case the very 1st query execution result is here:

DDL_chg3

PS.
Oracle resend column definitions to client after any changes that invalidate underlying cursor. For example I executed ALTER TABLE … DEALLOCATE UNUSED and observed the same effect.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s