Re: [HACKERS] Enum type emulation: problem with opaque type in PL/pgSQL functions

Max Fonin <fonin(at)ziet(dot)zhitomir(dot)ua> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> I guess the problem is that PL/pgSQL doesn't handle opaque type correctly.
>>
>> No it doesn't, which is not surprising considering that opaque isn't
>> really a type at all. The error message could be improved though :-(

> Well, I understood that the C is the only way very quick.
> Really, OPAQUE is just reference type like char* or void*, isn't it ?

No, it isn't a type at all. Opaque really means, in essence, that
you're not saying what the function's arguments or result are.

There are several reasons for handling datatype I/O routines that way:

1. The actual argument types include C strings, which aren't an SQL
datatype.

2. The I/O routines for a new type have to be defined before you can
say CREATE TYPE, and thus they can't name their true input or result
type anyway.

3. We have some "generic" I/O routines like array_in and array_out,
which work for multiple datatypes and so can't be declared as taking
any specific datatype.

BTW, the existing declarations of I/O routines for built-in types are
pretty messy and inconsistent (in particular, a lot of them are declared
to take or return int4 when they do no such thing). This could be
cleaned up somewhat if we invented an SQL type name for "C string",
but I don't see any way around the other two points.

regards, tom lane