Re: Invisible PROMPT2 - Mailing list pgsql-hackers

From David Fetter
Subject Re: Invisible PROMPT2
Date
Msg-id 20191113195704.GU7444@fetter.org
Whole thread Raw
In response to Re: Invisible PROMPT2  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Invisible PROMPT2
List pgsql-hackers
On Wed, Nov 13, 2019 at 03:58:38PM -0300, Alvaro Herrera wrote:
> 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:
>   PROMPT1="%w[$PROMPT1%w]"
> which I think is what you're saying.

PROMPT2="%w[$PROMPT1%w]", and basically yes.

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

Yeah, that's not so great for this usage.  I guess "expand variables"
could be a separate useful feature (and patch) all by itself...

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] gcc warning 'expression which evaluates to zero treated as a null pointer'
Next
From: Alvaro Herrera
Date:
Subject: Re: Creating foreign key on partitioned table is too slow