No, they are not. Empty strings are completely different from null, and if you go returning them or testing for equality, everything will break by random some single-digit percent of the time. The same for concatenating, taking the length or iterating.
I imagine there's some deterministic procedure to decide what leads to an empty string and what leads to null. The one thing I know is that if you insert it on a table, you will always get null.
It seems like reading the tale of a greek programmer cursed by the gods to work with madness itself.
It just needs to be enabled: https://docs.oracle.com/database/121/REFRN/GUID-D424D23B-093...
....
sorry
not possible (can't store empty string in a NULL col either)
for reals
(I once worked maintaining a MUD that used internal memory management and marked block terminals (which were unnecessary since it stored the length of blocks it had allocated) with ZZZ)
For example, I have a second name. Some people don't have second names. And some records we might not even know if such exists. Null means "unknown". Empty string cannot be equal to null.
We need that again, another new 0 concept to add to 0, to distinguish between "set-to-0" and "not-yet-set".
Maybe 2 new concepts, since null is also different from 0. 0 is a value, null is the absense of a value.
Not just as an idiom or implementation detail in a programming language, but as a general concept that may be used anywhere in life.
Without it, we have exactly these confusions and ambiguities and differences of opinion about how to do something or what something means or what something should mean.
For real though, no idea. I'm glad that I never had to touch Oracle.
When it comes to datatyping, (the whole point of data types in a db), null is its own datatype, so forcing the allowance of nulls to get blank strings is kinda stupid and only causes software/application level bugs.