Skip site navigation (1) Skip section navigation (2)

Re: \dn [PATTERN] handling not quite right...

From: Sean Chittenden <sean(at)chittenden(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Bugs List <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: \dn [PATTERN] handling not quite right...
Date: 2004-03-15 23:45:04
Message-ID: C87342FD-76DA-11D8-89C3-000A95C705DC@chittenden.org (view raw or flat)
Thread:
Lists: pgsql-bugs
>> I haven't looked in great detail into why this is happpening, but it
>> seems as though processNamePattern() doesn't handle ?'s correctly in
>> the negative lookahead context correctly.
>
> Negative lookahead context!?  You are several sigmas beyond the subset
> of regex functionality that \d and friends are intended to support.
> Given that we're defining * and ? as shell-style wildcards, it's not
> going to be feasible to handle very much of ordinary regex usage let
> alone advanced.

I was worried you'd say as much.  I'm in a situation where I've got a 
few hundred schemas floating around now and about half of them end with 
_log or _shadow and I was surprised at how non-trivial it was to filter 
out the _log or _shadow schemas with \dn.  I tried thinking up the psql 
equiv of tcsh's fignore but had no luck (ex:  set fignore = (\~ .o 
.bak)).

>> The more I think about this, a leading pipe could be used
>> to pipe the output to a utility, so that \dn | egrep -v '(log|shadow)
>> would work and would be the easiest solution.
>
> This on the other hand seems more like a potentially useful feature,
> although I'm unclear on what you expect to get sent through the pipe
> exactly --- you want column headers for instance?  What if you're using
> a nondefault display layout?

Instead of using printf(), fprintf(), fwrite(), or whatever it is that 
psql(1) uses internally for displaying result sets, have it use the 
following chunk of pseudo code:

if (pipe_symbol_found) {
	char buf[8192];
	size_t len = 0;
	memset(&buf, 0, sizeof(buf));

	fh = popen(..., "r+"); /* or setsocketpair() + fork() */
	fwrite(formatted_output_buffer, strlen(formatted_output_buffer), 1, 
fh);

	while((len = read(fileno(fh), buf, sizeof(buf)))) {
		fwrite(buf, len, 1, stdout);
	}
} else {
	/* whatever the current code does */
}

That doesn't take into account the set option that lets you write the 
output to a file, but that is trivial to handle.  To answer your 
question, I'd send _everything_ through the pipe and use the pipe as a 
blanket IO filter.  I haven't thought about this, but would it be 
possible to hand the data off to sh(1) and have it handle the 
pipe/redirection foo that way psql doesn't have to have any 
pipe/redirection brains?  If so, I think that'd be slick since you 
could do things like '\dn | tail -n +3 | grep -v blah' to handle your 
concern about having the header sent through and a utility not wanting 
it.

Too bad tee(1) doesn't support a -p option to have tee(1)'s argument 
sent to sh(1) or a pipe instead of a file, then there'd be some real 
interesting things that one could script.  Ex:

	\dn | tee -p 'head -n 3 >> /dev/stdout' | tail -n +3 | egrep -v 
'_(log|shadow)$'

Which'd show you the header, but everything after the header would be 
sent to egrep(1). I can't understand why win32 users think *NIX's CLI 
can be confusing.... *grin*.

Just some thoughts.  -sc

-- 
Sean Chittenden


In response to

pgsql-bugs by date

Next:From: beyaNet ConsultancyDate: 2004-03-16 12:31:43
Subject: could not create shared memory segment: Invalid argument
Previous:From: Tom LaneDate: 2004-03-15 23:10:33
Subject: Re: \dn [PATTERN] handling not quite right...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group