Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Well, our whole goal was to get rid of the opaque thing entirely so I am
> not sure if we want to keep that going. In fact, I am not sure it is
> even possible to remap opaque because it now is represented by so many
> other values.
We do still allow OPAQUE for triggers and datatype I/O functions, though
I would like to take that out by and by.
The only case where OPAQUE is rejected now but was allowed before is PL
language handlers. We could weaken that --- but since there are no
user-defined PL handlers in the wild (AFAIK anyway), I'd prefer not to.
My original thought about this was that people should run 7.3's
createlang script to load proper 7.3 language definitions into their 7.3
database. (This would not only fix the OPAQUE business but also replace
any remaining absolute paths for language handlers with the $libdir
form, which is an important 7.2 change that doesn't seem to have
propagated very well because people are just doing dumps and reloads.)
But I now see that this answer doesn't work for pg_dumpall scripts.
Does anyone see a cleaner answer than re-allowing OPAQUE for PL
handlers?
regards, tom lane