From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Teper <mark.teper@gmail.com>
cc: pgsql-sql@lists.postgresql.org
Subject: Re: plpython transforms vs. arrays
In-reply-to: 
 <CAMwSyGra+i1oL0pKgCv1WeE6GeBNhJJZTJ0bGxLNqJ0SFeEsVw@mail.gmail.com>
References: 
 <CAMwSyGra+i1oL0pKgCv1WeE6GeBNhJJZTJ0bGxLNqJ0SFeEsVw@mail.gmail.com>
Comments: In-reply-to Mark Teper <mark.teper@gmail.com>
	message dated "Thu, 02 May 2019 13:51:22 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <12204.1556852174.1@sss.pgh.pa.us>
Date: Thu, 02 May 2019 22:56:14 -0400
Message-ID: <12205.1556852174@sss.pgh.pa.us>
Precedence: bulk

Mark Teper <mark.teper@gmail.com> writes:
> The problem is this produces an error that transforms for type "real"
> doesn't work.  It doesn't seem to allow for transforms on array's as
> opposed to underlying types.  Is it possible to tell it to apply the
> transform to the array?

Yeah, see PLy_input_setup_func and PLy_output_setup_func, which both
say

     * Choose conversion method.  Note that transform functions are checked
     * for composite and scalar types, but not for arrays or domains.  This is
     * somewhat historical, but we'd have a problem allowing them on domains,
     * since we drill down through all levels of a domain nest without looking
     * at the intermediate levels at all.

At least for arrays, it might be sufficient to switch the order of the
array-lookup and transform-lookup cases to fix this.  I don't think
anyone's felt motivated to look into that, up to now.

			regards, tom lane