Re: Tab completion for SET TimeZone

From: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Tab completion for SET TimeZone
Date: 2022-03-18 00:35:10
Message-ID: 87czikrtc1.fsf@wibble.ilmari.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari(at)ilmari(dot)org> writes:
>> I just noticed I left out the = in the match check, here's an updated
>> patch that fixes that.
>
> Hmm .... is that actually going to be useful in that form?
> Most time zone names contain slashes and will therefore require
> single-quoting. I think you might need pushups comparable to
> COMPLETE_WITH_ENUM_VALUE.

With readline (which is what I tested on) the completion works with or
without a single quote, but the user has to supply the quote themselves
for non-identifier-syntax timezone names.

I wasn't aware of the difference in behaviour with libedit, but now that
I've tested I agree that quoting things even when not strictly needed is
better.

This does however have the unfortunate side effect that on readline it
will suggest DEFAULT even after a single quote, which is not valid.

> Also, personally, I'd rather not smash the names to lower case.
> I think that's a significant decrement of readability.

That was mainly for convenience of not having to capitalise the place
names when typing (since they are accepted case insensitively). A
compromise would be to lower-case it in the WHERE, but not in the
SELECT, as in the attached v3 patch.

I've tested this version on Debian stable with both readline 8.1-1 and
libedit 3.1-20191231-2.

- ilmari

Attachment Content-Type Size
v3-0001-Add-tab-completion-for-SET-TimeZone-TO.patch text/x-diff 2.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Japin Li 2022-03-18 00:38:33 Re: Support logical replication of DDLs
Previous Message Japin Li 2022-03-18 00:25:24 Re: Support logical replication of DDLs