From: | Thomas Hallgren <thomas(at)tada(dot)se> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: User Defined Types in Java |
Date: | 2006-02-09 13:27:42 |
Message-ID: | 43EB434E.6070900@tada.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martijn van Oosterhout wrote:
> On Thu, Feb 09, 2006 at 01:53:13PM +0100, Thomas Hallgren wrote:
>
>>> If you look at the code it says in a comment:
>>>
>>> /*
>>> * Only C-coded functions can be I/O functions. We
>>> enforce this
>>> * restriction here mainly to prevent littering the
>>> catalogs with
>>> * shell types due to simple typos in user-defined function
>>> * definitions.
>>> */
>>>
>>>
>> Ouch. Any chance of getting this changed? If we can agree on a good design
>> I'd be happy to implement and submit it.
>>
>
> Actually, I'm think this whole automatic creation of a shell-type a bit
> silly anyway. Why not simply solve the problem directly like so:
>
> CREATE TYPE complex AS SHELL;
>
> or
>
> DECLARE TYPE complex;
>
> Don't beat around the bush, say what you mean.
>
> Thoughts?
>
I'd perhaps take it even further. Why not just:
CREATE TYPE complex;
similar to an anonymous struct in C. My favorite alternative is to do
something like this:
CREATE TYPE complex (
internallength = 16,
input = complex_in,
output = complex_out,
...
AS 'filename' LANGUAGE C
);
A construct like that would remove a lot of clutter (and source of
errors). The IMMUTABLE STRICT along with all return and parameter types
are pre-defined anyway and the likelihood of the functions living in
different files (or as in my case, different classes) or using different
languages for one specific type is second to none.
Regards,
Thomas Hallgren
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-02-09 14:09:45 | Re: Schema search for default operator classes (was: [ADMIN] Cross schema Primary Key Indexes problem with datatype in the public schema) |
Previous Message | korry | 2006-02-09 13:12:28 | Re: pg_hba.conf alternative |