Re: Bugs: Programming Language Functions

On Tue, 11 Apr 2000, Tom Lane wrote:
> "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.)

yup, that's exactly what I did, but the last version of PgSQL I worked with
used TUPLE rather than TupleTableSlot, although I had to give my own prototype
for GetAttributeByName(). The previous version I worked with gave my both the
typedef and the prototype :-)

I'm certainly not doing anything that I would call a serious amount of
extension development - just one simple function which used to work by
following the simple instructions in the docs and no longer does.

The ability to add this type of extension to PgSQL has always been one of it's
major plus points and is one of the reasons I've been using it since the
Postgres95 days.

>
> 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.

OK, sorry that was a bad choice of header file, but it is, I'm pretty sure,
where GetAttributeByName() *used* to be defined. I just feel there should be
some nice easy header file for people to include who want to write a simple C
function which can access data from the database and return a valid type.

>
> > 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...
>

Depends on the complexity of the extension :-) If it's something which only has
to pull values out and return a value then this is likely to be the only
problem.

My own particular problem simply pulls out an integer and a (text *) from a
varchar. It then goes away and does some calculations based on these values and
another external file (in fact it does a system() to run an external program
which does these calculations). It then build a 'text' structure containing the
result.

With the exception of the prototypes and the typedef for TUPLE this has worked
without change since Postgres95.

Andrew

--
Dr. Andrew C.R. Martin EMail: a(dot)c(dot)r(dot)martin(at)reading(dot)ac(dot)uk (work)
Lecturer in Bioinformatics andrew(at)stagleys(dot)demon(dot)co(dot)uk (home)
University of Reading
Tel.: +44 (0)118 987 5123x7022 Fax: +44 (0)118 931 0180