Re: Invisible PROMPT2

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Invisible PROMPT2
Date: 2019-11-13 18:58:38
Message-ID: 20191113185838.GA11026@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2019-Nov-13, David Fetter wrote:

> On Wed, Nov 13, 2019 at 03:06:08PM -0300, Alvaro Herrera wrote:
> > On 2019-Nov-13, David Fetter wrote:
> >
> > > On Wed, Nov 13, 2019 at 09:47:01AM -0500, Tom Lane wrote:
> >
> > > > > How about a circumfix directive (like the existing %[ ... %])
> > > > > that replaces everything inside with whitespace, but keeps the width?

> > This seems way too specific to me. I like the "circumfix" directive
> > better, because it allows one to do more things. I don't have any
> > immediate use for it, but it doesn't seem completely far-fetched that
> > there are some.

> So something like %w[...%w] where people could put things like PROMPT1
> inside?

Hmm, (I'm not sure your proposed syntax works, but let's assume that
it does.) I'm saying you'd define
\set PROMPT1 '%a%b%c '
\set PROMPT2 '%w[%a%b%c %w]'

and you'd end up with matching indentation on multiline queries.

I'm not sure that we'd need to make something like this work:
which I think is what you're saying.

We already have "%:PROMPT1:" but that expands to the literal value of
prompt1, not to the value that prompt1 would expand to:

55432 13devel 11214=# \set PROMPT2 'hello %:PROMPT1: bye'
55432 13devel 11214=# select<Enter>
hello %[%033[35m%]%> %:VERSION_NAME: %p%[%033[0m%]%R%# bye

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-11-13 19:20:57 Re: AtEOXact_Snapshot timing
Previous Message Mukesh Chhatani 2019-11-13 18:52:13 Re: BUG #16109: Postgres planning time is high across version - 10.6 vs 10.10