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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers