Re: \dn [PATTERN] handling not quite right...
От | Sean Chittenden |
---|---|
Тема | Re: \dn [PATTERN] handling not quite right... |
Дата | |
Msg-id | C87342FD-76DA-11D8-89C3-000A95C705DC@chittenden.org обсуждение исходный текст |
Ответ на | Re: \dn [PATTERN] handling not quite right... (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-bugs по дате отправления: