I'm not suggesting that we remove the current way of doing things. I
understand that if we did that, it would cause problem for everyone that
has created scalar types up to this day. What I'm proposing is an
alternative way of doing this, not a replacement. And as things stand
today, I'd be happy if this alternative way was the only way to create a
type that didn't use C functions (hence, no need for a special construct
to create a shell type). That wouldn't break anything.
What I'm proposing should be an addition that also can be seen as the
beginning of a path to migrate the CREATE TYPE construct to conform with
the SQL 2003 standard.
Regards,
Thomas Hallgren
Tom Lane wrote:
> Thomas Hallgren <thomas@tada.se> writes:
>
>> 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?
>>
>
> (1) backwards compatibility
> (2) inability to ever add a fourth optional argument without creating
> a flag day for everyone
>
> I'm all for cleaning up the handling of shell types (and in fact have
> had that on my personal TODO list for ages). But I see zero if not
> negative usefulness in these ideas about changing CREATE TYPE. The
> certain outcome of that is to import all the complications of CREATE
> FUNCTION into CREATE TYPE, and for what gain?
>
>
