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:
execution 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.
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:
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.