Skip site navigation (1) Skip section navigation (2)

Re: Bugs: Programming Language Functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Andrew C(dot)R(dot) Martin" <a(dot)c(dot)r(dot)martin(at)reading(dot)ac(dot)uk>
Cc: interfaces(at)postgresql(dot)org, docs(at)postgresql(dot)org, hackers(at)postgresql(dot)org
Subject: Re: Bugs: Programming Language Functions
Date: 2000-04-11 14:52:26
Message-ID: 734.955464746@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-docspgsql-interfaces
"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

In response to

Responses

pgsql-docs by date

Next:From: Bruce MomjianDate: 2000-04-11 14:54:57
Subject: Update of doc TODO list for 7.0
Previous:From: Bruce MomjianDate: 2000-04-11 14:45:59
Subject: Re: Updated docs needed for 7.0

pgsql-interfaces by date

Next:From: Andrew C.R. MartinDate: 2000-04-11 15:38:58
Subject: Re: Bugs: Programming Language Functions
Previous:From: Paolo SommarugaDate: 2000-04-11 14:23:56
Subject: Re: Why fields order is wrong ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group