Re: [PATCHES] libpq type system 0.9a - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] libpq type system 0.9a
Date
Msg-id 8322.1207689484@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] libpq type system 0.9a  ("Merlin Moncure" <mmoncure@gmail.com>)
List pgsql-hackers
"Merlin Moncure" <mmoncure@gmail.com> writes:
>>> Actually I was thinking more about disk footprint.  Andrew's comment is
>>> correct if you work with statically linked code where the compiler pulls
>>> out only the needed .o files from a .a library, but that's pretty out of
>>> fashion these days.  Most people are dealing with a monolithic libpq.so
>>> and might carp a bit if it gets 25% or 50% bigger for stuff that doesn't
>>> interest them.

> on my box, the .so went from 118k to 175k. while this is significant
> in percentage terms, I don't think redhat is going to complain about
> 57k (correct me if I'm wrong here).

Yipes, 48% growth in the binary already?  That's much higher than
I'd expected from my quick source-code count, even with the scarcity of
comments.  What happens by the time the feature actually becomes mature?

Yes, I could see Red Hat complaining about that.  I'd rather have libpq
(as it currently stands) included in core RHEL, and "libpqtypes" as an
optional extra, than have a monolithic library get booted out to extras
altogether.  It could happen.  Don't think they don't see us as a
secondary objective ... mysql still has a lot more mindshare.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: Allow COPY from STDIN to absorb all input before throwing an error
Next
From: Tom Lane
Date:
Subject: Re: Allow COPY from STDIN to absorb all input before throwing an error