Re: Proposal: %T Prompt parameter for psql for current time (like Oracle has)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Kirk Wolak <wolakk(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, amborodin86(at)gmail(dot)com, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, samokhvalov(at)gmail(dot)com
Subject: Re: Proposal: %T Prompt parameter for psql for current time (like Oracle has)
Date: 2023-04-09 01:54:38
Message-ID: 3673996.1681005278@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <stark(at)mit(dot)edu> writes:
> I'm not sure if the *prompt* is a sensible place for it though. The
> place it seems like it would be most useful is reading the output of
> script executions where there would be no prompts. Perhaps it's the
> command tags and \echo statements that should be timestamped.

Hmm, that is an interesting idea. I kind of like it, not least because
it eliminates most of the tension between wanting a complete timestamp
and wanting a short prompt. Command tags are short enough that there's
plenty of room.

> And I think experience shows that there are three reasonable formats
> for dates, the default LC_TIME format, ISO8601, and a relative
> "seconds (with milliseconds) since starting". I think having a feature
> that doesn't support those three would feel incomplete and eventually
> need to be finished.

Yeah, I don't believe that one timestamp format is going to satisfy
everyone. But that was especially true when trying to wedge it
into the prompt, where the need for brevity adds more constraints.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2023-04-09 01:55:33 Re: Direct I/O
Previous Message Tom Lane 2023-04-09 01:50:49 Re: Commitfest 2023-03 starting tomorrow!