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 <[EMAIL PROTECTED]> 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?
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
