From: | Thomas Hallgren <thomas(at)tada(dot)se> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: User Defined Types in Java |
Date: | 2006-02-12 20:13:07 |
Message-ID: | 43EF96D3.8080903@tada.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2006-02-12 20:29:02 | Re: Krb5 & multiple DB connections |
Previous Message | Bruce Momjian | 2006-02-12 20:06:06 | Re: Krb5 & multiple DB connections |