Re: [HACKERS] psql issues

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > 1) Is it just me or is psql the only application that uses libpq's
> > PQprint()? I think both parties involved could benefit if the PQprint was
> > moved to or integrated into psql. Or perhaps a libpqprint as a compromise?
>
> The print support in libpq is certainly ugly --- we've got two or three
> generations of print subroutines in there, and are maintaining 'em all
> because we have no idea what existing applications may depend on each.
> I'd be real hesitant to rip any of them out. However, if you can
> improve on them, a new fourth-generation subroutine isn't going to
> hurt anyone ;-).

Let me add something. I have no problem with #ifdef NOT_USED certain
function bodies, and replacing them with something else like this:

int libfunc()
{
#ifdef NOT_USED
old_lib_code
...
#else
fprintf(stderr,"This function is currently unsupported.\n");
fprintf(stderr,"If you want to use it, contact the bugs mailing list.\n");
exit(1);
#endif

and if we can get through one full release with the code like this, we
can remove the function entirely.

This seems to be the only clean way to remove much old cruft in library
code.

I am sure some of the old code was for the old pgsql 'monitor' program
that we trashed early on, so I doubt people are using any of that print
code.

>
> I'm not sure whether moving them to a separate library would be worth
> the trouble. It might be worth breaking up fe-print.c more, so that
> a statically linked app will only pull in the subroutines it's actually
> using. But for users of shared libraries this doesn't matter anyway.
>

I agree. Keep it in libpq because it may be useful for someone else.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026