From: | andrew <andrew(dot)ylzhou(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: user defined function |
Date: | 2006-01-26 11:01:22 |
Message-ID: | 29d3b0b90601260301u6910457au380de9743c90e51a@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thanks, Tom. It is done by modifying coerce_type() and
can_coerce_type(). The reason I have to keep to verson 7.3 is I am
working on a research prototype that is built over pgsql 7.3. I need
the extra functions provided by that prototype.
On 1/25/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> andrew <andrew(dot)ylzhou(at)gmail(dot)com> writes:
> > Sorry, I modified the parser code and forgot abt it. Now there is no
> > problem in creating the function. But there is another problem. I
> > create a function to accept record type parameter. But when I call it
> > on a specific composite type, error is reported. The followings are
> > what I have done:
>
> > backend> create function complete(record) returns int4 as
> > '$libdir/qualityudf' language C
> > QUERY: create function complete(record) returns int4 as
> > '$libdir/qualityudf' language C
>
> > backend> select *, complete(Person) from Person
> > QUERY: select *, complete(Person) from Person
>
> > ERROR: Function complete(person) does not exist
>
> Hmm. Looking at parse_coerce.c, 8.1 is the first release that thinks
> named composite types can be coerced to RECORD. I think you may be
> forced to upgrade if you want this to work. Changing 7.3's coerce_type()
> to allow this case would be simple enough, but I think you are still
> going to be minus a lot of infrastructure that's required to make it
> actually do anything useful :-(
>
> regards, tom lane
>
--
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Uroš Gruber | 2006-01-26 11:15:58 | many row updates |
Previous Message | Paul Mackay | 2006-01-26 10:06:24 | Physical column size |