Re: [HACKERS] Missing array support - Mailing list pgsql-patches

From Joe Conway
Subject Re: [HACKERS] Missing array support
Date
Msg-id 3F00D7AE.9090503@joeconway.com
Whole thread Raw
In response to Re: [HACKERS] Missing array support  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Missing array support  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Tom Lane wrote:
> What I've done instead is not to weaken type checking, but simply to
> postpone all checking of the body of a SQL function to runtime if it
> has any polymorphic arguments.  At runtime, we know the actual types
> for the arguments, and we know the actual assigned result type, and
> then we can run the normal checking operations without any problem.

As usual, big improvement in what I submitted. Thanks.

> Applied patch attached, just FYI.  (It still needs documentation
> updates, which I trust you will supply later.)

Yup, you have my gold plated IOU on the doc cleanup for all this stuff.

One note; this change

>   Oid
> ! get_fn_expr_rettype(FunctionCallInfo fcinfo)
>   {
[snip]
>   Oid
> ! get_fn_expr_rettype(FmgrInfo *flinfo)
>   {

is a good example why some things, particularly PLs, are better off
being in the main source tree rather than on gborg (or someplace else).
PL/R uses get_fn_expr_rettype() and get_fn_expr_argtype(), so it's now
broken as of CVS tip :(

I know the license issue is the primary reason why PL/R is not in the
main source tree, but I bring it up because I think the tendency to push
things out and over to gborg has been too strong lately.

Joe


pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Patch for listing runtime option details through server executable (pg_guc)
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Missing array support