Peter Eisentraut <peter_e@gmx.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 ;-).
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.
> 2) Regarding TODO item "Allow psql \copy to allow delimiters": What
> precisely is the difference between:
> => \copy my_table to file
> => copy my_table to 'file';
Those two are *very significantly* different: the former reads or writes
a file from psql, using the client's access rights (after transporting
the data across the frontend/backend channel, of course). The latter
reads or writes a file from the backend, using the backend's access
rights (and the psql process never even sees the data).
The two processes are not necessarily even on the same machine, so you
may be talking about two completely different filesystems. We restrict
backend copy to the Postgres superuser for obvious security reasons.
Therefore, it'd be real nice if psql's \copy support was more complete.
> Correct me if I'm wrong, but I believe the use of PG{get|put}line() for
> the \copy would have to be scratched if one would want to use delimiters.
No. get/putline are just the implementation of the data transport step
mentioned above. If psql would send a DELIMITER clause in the COPY TO
STDIN or COPY FROM STDOUT command that it sends to the backend to start
a \copy operation, then the right things would happen. Should be a
pretty localized change. There might be some other COPY options that
would be worth supporting ... I forget.
BTW, I suspect that there may be some bugs in get/putline and/or psql.c
and/or the backend's copy.c that cause the data transport not to be
perfectly 8-bit-clean. In particular, backslash quoting of control
characters needs to be looked at. There is (or should be) a TODO item
about this. If you feel like digging into that area, it'd be useful.
> 3) Is anyone doing anything major on psql right now or would anyone mind
> if I undertake a major code clean up on it? Or is everyone completely
> comfortable with 350-line functions with 7 levels of indentation?
Go for it --- it's pretty ugly all right, and far from the fine example
of how to code a Postgres client that it ought to be ;-).
Make sure you start from current CVS sources, because I just finished
hacking up psql (and libpq) to eliminate line length restrictions.
Offhand I don't know of any other major changes pending in that code.
(Anybody want to speak up here and say "I'm doing something"?)
regards, tom lane
