Re: Bugs: Programming Language Functions

"Andrew C.R. Martin" <a(dot)c(dot)r(dot)martin(at)reading(dot)ac(dot)uk> writes:
> This then links onto the code installation problems, as the header
> files in the installed include directory do not have a typedef for
> TupleTableSlot. This is defined in .../src/include/executor/tuptable.h
> Just copying this across to the installation directory causes no end
> of other files to be needed as well (e.g. storgae/buf.h,
> access/tupdesc.h, access/htup.h - and these in turn require loads of
> other files.....)

Yes, this has been complained of before: trying to write an extension
that touches anything but the most basic system types requires including
a mess of files that we don't normally export ... and we don't really
*want* to export the whole set of include files. For the moment,
I'd suggest compiling with a -I pointing at a source tree rather than
the install tree. (If you're doing any serious extension development,
you surely have a source tree around for reference, so I don't think
this is totally unreasonable.)

Bruce did some work a while ago to eliminate unnecessary cross-includes,
so it could be that in 7.0 it would be easier to deal with the problem.
But really, someone needs to go through the backend header files and
figure out what makes sense to export.

> Surely TupleTableSlot should be defined in libpq-fe.h as should the
> prototype for GetAttributeByName().

Surely *not*. Neither the type nor the function exist in the frontend.
We may need to export more backend header files, but confusing backend
and frontend isn't going to help anyone.

> It would be nice to have TUPLE
> #defined as TupleTableSlot so that old code doesn't break!!!!

If that were the only thing breaking old code, I'd agree with you,
but extensions usually need to be looked at for every version anyway...

regards, tom lane