Hi Connor, didn't you mentioned this bug over a year ago in one of your other Flashback Archive video / articles? If so, any idea why has it taken so long to patch, especially given how simple a fix it appears to be and the quite severe implications it has on the shared pool?
I don't decide bug priorities :-) but generally what happens is - the more customers that are impacted, the greater the priority. If I had to guess, this one sat lower in the chain until more and more people started taking advantage of FDA, which naturally raises the visbility.
Connor, do you take requests? Maybe do a video on using expdp/impdp between different platforms (between little endian/big endian). Can just individual tables/views be moved between the different platforms/endian types with Datapump?
You might think that, because Oracle knows the exact field length at table design time, that they would not use extra bytes to record the field length. It turns out that this is not the case, and that there is literally zero advantage of using CHAR over VARCHAR2, only disadvantages (e.g. storing padding, another curious decision on Oracle's part).
Hi Connor, didn't you mentioned this bug over a year ago in one of your other Flashback Archive video / articles? If so, any idea why has it taken so long to patch, especially given how simple a fix it appears to be and the quite severe implications it has on the shared pool?
I don't decide bug priorities :-) but generally what happens is - the more customers that are impacted, the greater the priority. If I had to guess, this one sat lower in the chain until more and more people started taking advantage of FDA, which naturally raises the visbility.
Connor, do you take requests? Maybe do a video on using expdp/impdp between different platforms (between little endian/big endian). Can just individual tables/views be moved between the different platforms/endian types with Datapump?
Platform, endian etc makes no difference with DataPump. It just works!
BTW why is Operation a VARCHAR2(1) not a CHAR(1)? ,)
Because varchar2 is the only game in town :-)
You might think that, because Oracle knows the exact field length at table design time, that they would not use extra bytes to record the field length. It turns out that this is not the case, and that there is literally zero advantage of using CHAR over VARCHAR2, only disadvantages (e.g. storing padding, another curious decision on Oracle's part).