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

Re: [GENERAL] SPI & file locations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
Cc: Mike Mascari <mascarm(at)mascari(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] SPI & file locations
Date: 2000-05-27 05:49:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> :-) I expect no less (than to work harder, of course....).  Why not do
> something like that, other than the 'out-of-sight, out-of-mind'
> problem?  Or, to put it far more bluntly, the SPI installation is very
> broken if the SPI developer has to go around manually installing
> header files that make install should have automatically taken care
> of.

Agreed, but I'm worried about the 'out-of-sight, out-of-mind' aspect.

>> The more serious problem is "what else might an SPI module need besides
>> spi.h".

> What else indeed.  Isn't spi.h the exported SPI itself?  We seem to
> have a very poorly defined line between exported and private
> interfaces

Ah-hah, I think you and I are on exactly the same wavelength there.

My whole problem with the spi.h-imports-88-headers business is that it
exposes in gory detail the fact that *we have absolutely no idea* what
we consider an exported backend interface and what we don't.  I don't
like the idea of an automatic tool that exports whatever it thinks might
be needed, because if we let ourselves go down that path we will very
soon find ourselves trying to preserve backwards compatibility with
something that should never have been exported at all.

Basically I feel that this is a problem that requires some actual
thought and design judgment.  I don't want to see us substituting
a one-liner script hack for design judgment.  OTOH, I don't really
want to do the legwork myself (lame excuse: never having written
an SPI module myself, I have little idea what they need to see).
I'm just concerned about the long-term consequences of taking the
easy way out.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2000-05-27 06:06:00
Subject: Re: Rename pl/tcl to pl/pltcl
Previous:From: Alfred PerlsteinDate: 2000-05-27 05:43:24
Subject: Re: Rename pl/tcl to pl/pltcl

pgsql-general by date

Next:From: planx plnetxDate: 2000-05-27 11:02:37
Subject: where find postgres7.0 RPMs?
Previous:From: Frank P. MilesDate: 2000-05-27 04:53:21
Subject: Bug in char_length() in 7.0?

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