While looking at the proposed ALTER TYPE patch, I got annoyed
about the amount of cruft that exists in typecmds.c to deal with
ancient, non-type-safe ways of declaring type I/O functions.
The CREATE TYPE reference pages explains this well enough:
Before PostgreSQL version 8.2, the shell-type creation syntax CREATE
TYPE name did not exist. The way to create a new base type was to
create its input function first. In this approach, PostgreSQL will
first see the name of the new data type as the return type of the
input function. The shell type is implicitly created in this
situation, and then it can be referenced in the definitions of the
remaining I/O functions. This approach still works, but is deprecated
and might be disallowed in some future release. Also, to avoid
accidentally cluttering the catalogs with shell types as a result of
simple typos in function definitions, a shell type will only be made
this way when the input function is written in C.
In PostgreSQL versions before 7.3, it was customary to avoid creating
a shell type at all, by replacing the functions' forward references to
the type name with the placeholder pseudo-type opaque. The cstring
arguments and results also had to be declared as opaque before 7.3. To
support loading of old dump files, CREATE TYPE will accept I/O
functions declared using opaque, but it will issue a notice and change
the function declarations to use the correct types.
It might be too soon to drop the automatic-shell-type hack, but I think
a strong case can be made for dropping the automatic conversion of I/O
functions declared with OPAQUE. 7.3 was released in 2002, so any code
following the old way is now old enough to vote. Does anyone really think
that a C function written against 7.2 or earlier would work in a modern
server without bigger changes than that?
The other remaining uses of OPAQUE are for old-style declarations of
trigger functions and language handler functions. Again it seems very
unlikely that anyone still has code following the old style, or that
this'd be their biggest portability issue if they did.
In short, I propose ripping out OPAQUE entirely.
I wouldn't lobby too hard against removing the auto-shell-type hack
either, but it's not actually type-unsafe and it doesn't require
very much code to support, so the case for removing it seems a lot
weaker than that for getting rid of OPAQUE.
Thoughts?
regards, tom lane