Martijn van Oosterhout wrote:
> The docs are your friend, see[1] in particular the input_function and
> the receive_function.
>
> [1] http://www.postgresql.org/docs/8.1/interactive/sql-createtype.html
>
>
Ok, so there are two 'optional' arguments. Following my suggestion, the
input and receive function would always take 3 arguments. Then, it's up
to the function as such if it makes use of them or not. Do you see any
problem with that? Is it bad from a performance perspective to always
produce the values for the additional arguments? If so, an additional
clause 'WITH EXTENDED PARAMETERS' (pending better suggestions :-) )
could be added to the CREATE TYPE.
>> I guess the pg_dump problem that you're thinking of is that there's no
>> way to associate the functions with the type that they would belong to.
>> Perhaps this could be done by adding a 'protype oid' column to the
>> pg_proc table? Introducing that would probably help introducing SQL 2003
>> semantics further on (I'm thinking of methods that belongs to types. Not
>> very different from a function taking the type as it's first argument).
>>
>
> I think the pg_dump is the fact that pg_dump needs to produce output
> that can be parsed to recreate the type and your suggestion only covers
> a very small set of possible type definitions (all in same lib,
> external func name = postgres func name, etc).
>
>
That's very intentional. It will keep the functions of a type
declaration in one place. I seriously doubt that there's an advantage to
splitting functions for a single type between different libraries. I
just can't see why or when that would be a good thing. Can you?
I also find it hard to come up with reasons why the PostgreSQL function
name should be different from the name of the C function. I find no
reasons at all that would motivate all the clutter equipped with the
current construct.
> Hopefully something will be considered, but the first person who
> produces a patch will probably get priority :)
>
>
I kind of guessed that would be the answer. I took a quick glance at the
yacc grammar. Seems any of the suggestions would be possible to
implement. So which is it?
CREATE TYPE complex;
CREATE TYPE complex AS SHELL;
DECLARE TYPE complex;
The first one has my vote.
Regards,
Thomas Hallgren