Re: [HACKERS] psql issues
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] psql issues |
Дата | |
Msg-id | 6104.938186974@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | psql issues (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: [HACKERS] psql issues
(Bruce Momjian <maillist@candle.pha.pa.us>)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: