From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Hallgren <thomas(at)tada(dot)se> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: User Defined Types in Java |
Date: | 2006-02-13 16:41:33 |
Message-ID: | 2084.1139848893@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Hallgren <thomas(at)tada(dot)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?
> So which is it?
> CREATE TYPE complex;
> CREATE TYPE complex AS SHELL;
> DECLARE TYPE complex;
I'd go with the first.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-02-13 16:54:43 | Re: Why don't we allow DNS names in pg_hba.conf? |
Previous Message | Tom Lane | 2006-02-13 16:24:35 | Re: Postgresql crash (signal 11). keywords: distinct, subselect, union |