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?

2) Regarding TODO item "Allow psql \copy to allow delimiters": What
precisely is the difference between:
=> \t
=> \o file
=> select * from my_table;
and
=> \copy my_table to file
or, for that matter,
=> copy my_table to 'file';
besides perhaps their internal execution path? The third variant already
allows the use of delimiters (USING DELIMITERS '*'), and so does the first
one (\f). (Speaking of which, does anyone know how to enter in effect \f
<TAB>?)

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.

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?

-- 
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e



Fri, 24 Sep 1999 12:38:19 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
psql issues
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

Fri, 24 Sep 1999 11:29:34 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] psql issues 
> 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 ;-).

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@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 26 Sep 1999 20:17:11 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] psql issues