Thread: Exports from postgres

While working on the VC++ build, I initially (accidentally) built
postgres.exe witohut exporting all symbols (because VC++ doesn't have a
builtin functionality to do export-all). When enabling it to export all,
I noticed the binary increased more than 30% in size, and the linker
time increased around 500%. (The reason the function is not in vc++ is
that you're really not supposed to do full-exports from EXEs and
DLLs...)

Which brings me to the question - would it be reasonable to create a
.DEF file listing which symbols are exported from the postgres binary to
addon modules? Sort of the same way libpq does it, though of course with
a much more extensive list of functions. I have a feeling this might be
both more work than wanted, and something contrary to some piece of
design, but I'm throwing the question out to get some expert comments on
it.

//Magnus

On Sat, Apr 29, 2006 at 10:56:20AM +0200, Magnus Hagander wrote:
> While working on the VC++ build, I initially (accidentally) built
> postgres.exe witohut exporting all symbols (because VC++ doesn't have a
> builtin functionality to do export-all). When enabling it to export all,
> I noticed the binary increased more than 30% in size, and the linker
> time increased around 500%. (The reason the function is not in vc++ is
> that you're really not supposed to do full-exports from EXEs and
> DLLs...)

Interesting. Exporting all symbols on linux causes bloat for libraries
but not for executables. The only effect is slightly increased load
time. I can't say the linking has taken any noticable period of time on
my 5 year old machine, but the makefiles do a lot of partial linking
which may not be the case for you.

> Which brings me to the question - would it be reasonable to create a
> .DEF file listing which symbols are exported from the postgres binary to
> addon modules? Sort of the same way libpq does it, though of course with
> a much more extensive list of functions. I have a feeling this might be
> both more work than wanted, and something contrary to some piece of
> design, but I'm throwing the question out to get some expert comments on
> it.

Ouch. the problem being that currently we have no idea what functions
are being used by external modules, but probably a lot. Also, all the
stuff in pg_proc refers to functions internally, does postgres still
find them if you don't export them?

Can you find any scale effects? If you cut the symbol list in half,
does that have much effect? Or do we really need to whittle it down
heaps to be useful...

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

"Magnus Hagander" <mha@sollentuna.net> writes:
> Which brings me to the question - would it be reasonable to create a
> .DEF file listing which symbols are exported from the postgres binary to
> addon modules?

No, I'd not think this is a good idea.  Unlike libpq, there's no clear
demarcation of an intended API, and no really good reason to create one.
        regards, tom lane

> > Which brings me to the question - would it be reasonable to
> create a
> > .DEF file listing which symbols are exported from the
> postgres binary
> > to addon modules?
>
> No, I'd not think this is a good idea.  Unlike libpq, there's
> no clear demarcation of an intended API, and no really good
> reason to create one.

That's kind of what I thought. Thanks for the verification.

//Magnus