From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew C.R. Martin <a.c.r.martin@reading.ac.uk>
Cc: interfaces@postgresql.org
Cc: docs@postgresql.org
Cc: hackers@postgresql.org
Subject: Re: Bugs: Programming Language Functions
Date: Tue, 11 Apr 2000 10:52:26 -0400
Message-ID: <734.955464746@sss.pgh.pa.us> (raw)
In-Reply-To: <00041112551002.24969@sapc13.rdg.ac.uk>
References: <00041112551002.24969@sapc13.rdg.ac.uk>
"Andrew C.R. Martin" <a.c.r.martin@reading.ac.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: tgl@sss.pgh.pa.us, a.c.r.martin@reading.ac.uk, interfaces@postgresql.org, docs@postgresql.org, hackers@postgresql.org
Subject: Re: Bugs: Programming Language Functions
In-Reply-To: <734.955464746@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox