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
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! |