Michael Samuel <michael@miknet.net> writes:
> I've been thinking about this, and I think the smartest way to implement
> %TYPE would be to have it as a special-case data type. So, the C
> representation of it would be something like this:
>
> struct PercentType {
> int datatype;
> void *data;
> };
>
> Note: I made the datatype field an int, but that may/may not be the
> correct datatype to use there.
>
> And basically, postgres can resolve at runtime what it should point to,
> and the code should have to deal with it, either via casting, or throwing
> an exception if it's unacceptable.
>
> Of course, there'd be a small overhead within the function, but it's a
> small price to pay for a robust implementation.
>
> As for operator overloading, a decision must be made whether you search
> for a more specific function first, or for a matching %TYPE.
Functions are stored in the pg_proc table. That table has 16 fields
which hold the OIDs of the types of the arguments. When searching for
a function, the types of the parameters are used to search the table.
We would have to figure out a way to store the %TYPE field instead.
Perhaps one approach would be to have a separate table which just held
%TYPE entries. Then pg_proc could hold the OID of the row in that
table. The parser code which hooks up function calls with function
definitions would have to recognize this case and convert the %TYPE
into the real type at that time. This would only be done if there was
no exact match, so there would only be a performance penalty when
%TYPE was used.
The code could be written such that a function which specified the
exact type would always be chosen before a function which used %TYPE.
However, a function which used %TYPE to specify the exact type would
be chosen before a function which specified a coerceable type.
Probably several other places would have to be prepared to convert an
entry in the new %TYPE table to an entry in the pg_type field. But
that could be encapsulated in a function.
Whether this is of any interest or not, I don't know.
Ian
