On fre, 2011-11-18 at 09:44 -0500, Tom Lane wrote:
> It wouldn't be that hard for elog.c to do strrchr(fname, '/') or
> something like that, but the idea that there are hundreds of full-path
> strings embedded in the executable is a bit annoying. I guess we
> could
> hope that the compiler is bright enough to store it only once per
> source
> file, so the actual space requirement may not be all *that* bad.
A look a the output of "strings" shows that the compiler does appear to
optimize this. So your suggestion is probably the way to go.
One thing that isn't so nice about all this is that it embeds the
personal directory structure of the builder of the binary into the
shipped product. But gcc's cpp doesn't like redefining __FILE__, so the
only way to get around that altogether would be to use something other
than __FILE__ and define that for all builds. Might not be worth it.
