|From:||Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Should contrib modules install .h files?|
|Views:||Raw Message | Whole Thread | Download mbox|
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
Tom> It's particularly bad for these cases, since what they demonstrate
Tom> is that it's impossible to build transform modules for plperl or
Tom> plpython out-of-tree at the moment.
Right. Both plperl and plpython install _some_ header files (which
behavior was added in the commit for the transforms feature), but they
don't install all of the header files that the existing transform
modules actually use. Is this supposed to be a principled choice, with
an out-of-tree transform expected to provide their own code instead of
using those headers, or is it just an oversight?
Tom> That doesn't seem to me to be something we should just ignore; it
Tom> goes against not only our larger commitment to extensibility, but
Tom> also the entire point of the transforms feature.
Yeah, if an out-of-tree data type can't provide a plperl or plpython
transform for itself, something's broken. And that does seem to be the
case at present.
|Next Message||Andrew Gierth||2018-08-02 23:31:21||Re: Should contrib modules install .h files?|
|Previous Message||Konstantin Knizhnik||2018-08-02 22:02:19||Re: [HACKERS] Cached plans and statement generalization|