"tanghy.f...@fujitsu.com" writes:
> I think 02b8048 forgot to free some used memory.
> Attached a tiny patch to fix it. Please have a check.
Right you are. Inspired by that, I tried running some tab-completion
operations under valgrind, and found another nearby leak in
patternToSQLRegex. Fixes
On Monday, January 31, 2022 3:35 AM, Tom Lane wrote:
> "tanghy.f...@fujitsu.com" writes:
> > Thanks for your V16 patch, I tested it.
> > The results LGTM.
>
> Pushed, thanks for looking.
I think 02b8048 forgot to free some used memory.
Attached a tiny patch to fix it. Please have a check.
Reg
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Tom Lane writes:
>>> We could do something hacky like matching case only when there's
>>> no longer any matching object names, but that might be too magic.
>> I experimented with that, and it actually doesn't seem as weird
>> as I feared. See
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Tom Lane writes:
>>> We could do something hacky like matching case only when there's
>>> no longer any matching object names, but that might be too magic.
>> I experimented with that, and it actually doesn't seem as weird
>> as I feared. See i
Tom Lane writes:
> I wrote:
>> =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
>>> First, as noted in the test, it doesn't preserve the case of the input
>>> for keywords appended to the query result. This is easily fixed by
>>> using `pg_strdup_keyword_case()`, per the first attached patch.
I wrote:
> =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
>> First, as noted in the test, it doesn't preserve the case of the input
>> for keywords appended to the query result. This is easily fixed by
>> using `pg_strdup_keyword_case()`, per the first attached patch.
> I thought about that,
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> First, as noted in the test, it doesn't preserve the case of the input
> for keywords appended to the query result. This is easily fixed by
> using `pg_strdup_keyword_case()`, per the first attached patch.
I thought about that, and intentionall
Tom Lane writes:
> "tanghy.f...@fujitsu.com" writes:
>> Thanks for your V16 patch, I tested it.
>> The results LGTM.
>
> Pushed, thanks for looking.
I wasn't following this thread, but I noticed a few small potential
improvements when I saw the commit.
First, as noted in the test, it doesn't
"tanghy.f...@fujitsu.com" writes:
> Thanks for your V16 patch, I tested it.
> The results LGTM.
Pushed, thanks for looking.
regards, tom lane
On Saturday, January 29, 2022 7:17 AM, Tom Lane wrote:
> Sigh ... per the cfbot, this was already blindsided by 95787e849.
> As I said, I don't want to sit on this for very long.
Thanks for your V16 patch, I tested it.
The results LGTM.
Regards,
Tang
On Saturday, January 29, 2022 1:03 AM, Tom Lane wrote:
> "tanghy.f...@fujitsu.com" writes:
> > I did some tests on it and here are something cases I feel we need to
> > confirm
> > whether they are suitable.
>
> > 1) postgres=# create table atest(id int, "iD" int, "ID" int);
> > 2) CREATE TABLE
"tanghy.f...@fujitsu.com" writes:
> I did some tests on it and here are something cases I feel we need to confirm
> whether they are suitable.
> 1) postgres=# create table atest(id int, "iD" int, "ID" int);
> 2) CREATE TABLE
> 3) postgres=# alter table atest rename i[TAB]
> 4) id"iD"
> 5) po
On Friday, January 28, 2022 5:24 AM, Tom Lane wrote:
> Here's a fleshed-out patch series for this idea.
Thanks for you patch.
I did some tests on it and here are something cases I feel we need to confirm
whether they are suitable.
1) postgres=# create table atest(id int, "iD" int, "ID" int);
2
On Tuesday, January 25, 2022 6:44 PM, Julien Rouhaud wrote:
> Thanks for updating the patch. When you do so, please check and update the
> commitfest entry accordingly to make sure that people knows it's ready for
> review. I'm switching the entry to Needs Review.
>
Thanks for your reminder. I
I spent some time contemplating my navel about the concerns I raised
upthread about double-quoted identifiers. I concluded that the reason
things don't work well in that area is that we're trying to get all the
work done by applying quote_ident() on the backend side and then
ignoring quoting consi
Hi,
On Tue, Jan 25, 2022 at 05:22:32AM +, tanghy.f...@fujitsu.com wrote:
>
> I tried to add a flag(casesensitive) in the _complete_from_query().
> Now the attached patch passed all the added tap tests.
Thanks for updating the patch. When you do so, please check and update the
commitfest ent
On Monday, January 24, 2022 6:36 PM, Peter Eisentraut
wrote:
> The way your patch works now is that the case-insensitive behavior you
> are implementing only works if the client encoding is a single-byte
> encoding. This isn't what downcase_identifier() does;
> downcase_identifier() always works
On 20.01.22 08:37, tanghy.f...@fujitsu.com wrote:
1. The downcasing logic in the patch bears very little resemblance
to the backend's actual downcasing logic, which can be found in
src/backend/parser/scansup.c's downcase_identifier(). Notably,
the patch's restriction to only convert all-ASCII st
On Sunday, January 16, 2022 3:51 AM, Tom Lane said:
> Peter Eisentraut writes:
> > The rest of the patch seems ok in principle, since AFAICT enums are the
> > only query result in tab-complete.c that are not identifiers and thus
> > subject to case issues.
>
> I spent some time looking at this p
Hi,
On Sat, Jan 15, 2022 at 01:51:26PM -0500, Tom Lane wrote:
>
> I spent some time looking at this patch. I'm not very happy with it,
> for two reasons:
> [...]
On top of that the patch doesn't apply anymore:
http://cfbot.cputube.org/patch_36_2979.log
=== Applying patches on top of PostgreSQL
Peter Eisentraut writes:
> The rest of the patch seems ok in principle, since AFAICT enums are the
> only query result in tab-complete.c that are not identifiers and thus
> subject to case issues.
I spent some time looking at this patch. I'm not very happy with it,
for two reasons:
1. The dow
On 07.01.22 06:17, tanghy.f...@fujitsu.com wrote:
On Friday, January 7, 2022 1:08 PM, Japin Li wrote:
+/*
+ * pg_string_tolower - Fold a string to lower case if the string is not quoted
+ * and only contains ASCII characters.
+ * For German/Turkish etc text, no change will be made.
+ *
+ * The
On Friday, January 7, 2022 1:08 PM, Japin Li wrote:
> +/*
> + * pg_string_tolower - Fold a string to lower case if the string is not
> quoted
> + * and only contains ASCII characters.
> + * For German/Turkish etc text, no change will be made.
> + *
> + * The returned value has to be freed.
> + */
On Fri, 07 Jan 2022 at 10:12, tanghy.f...@fujitsu.com
wrote:
> On Thursday, January 6, 2022 11:57 PM, Tom Lane wrote:
>>
>> Peter Eisentraut writes:
>> > So the ordering of the suggested completions is different. I don't know
>> > offhand how that ordering is determined. Perhaps it's depend
On Thursday, January 6, 2022 11:57 PM, Tom Lane wrote:
>
> Peter Eisentraut writes:
> > So the ordering of the suggested completions is different. I don't know
> > offhand how that ordering is determined. Perhaps it's dependent on
> > locale, readline version, or operating system. In any case
Peter Eisentraut writes:
> So the ordering of the suggested completions is different. I don't know
> offhand how that ordering is determined. Perhaps it's dependent on
> locale, readline version, or operating system. In any case, we need to
> figure this out to make this test stable.
I don'
On 10.09.21 15:50, tanghy.f...@fujitsu.com wrote:
(A test case for the enum case should be doable easily.)
Test added.
The enum test is failing on *some* platforms:
t/010_tab_completion.pl .. 26/?
# Failed test 'complete enum values'
# at t/010_tab_completion.pl line 211.
# Actual output
On Tuesday, September 7, 2021 5:25 PM, Peter Eisentraut
wrote:
>The coding of valid_input_text() seems a bit bulky. I think you can do
>the same thing using strspn() without a loop.
Thanks, modified in V9 patch.
>The name is also not great. It's not like other strings are not "valid".
Modi
On 23.06.21 14:43, tanghy.f...@fujitsu.com wrote:
I've updated the patch to V8 since Tom, Kyotaro and Laurenz discussed the lower
case issue of German/Turkish language at [1].
Differences from V7 are:
* Add a function valid_input_text which checks the input text to see if it only
contains alph
Hi
I've updated the patch to V8 since Tom, Kyotaro and Laurenz discussed the lower
case issue of German/Turkish language at [1].
Differences from V7 are:
* Add a function valid_input_text which checks the input text to see if it only
contains alphabet letters, numbers etc.
* Delete the flag se
Hi
I've updated the patch to V7 based on the following comments.
On Friday, April 23, 2021 11:58 AM, Kyotaro Horiguchi
wrote
>All usages of pg_string_tolower don't need a copy.
>So don't we change the function to in-place converter?
Refer to your later discussion with Tom. Keep the code as i
On Fri, 2021-04-23 at 14:44 +0900, Kyotaro Horiguchi wrote:
> > The two examples I know of offhand are in German (eszett "ß" downcases to
> > "ss") and Turkish (dotted "Í" downcases to "i", likewise dotless "I"
>
> According to Wikipedia, "ss" is equivalent to "ß" and their upper case
> letters ar
FWIW...
At Fri, 23 Apr 2021 00:17:35 -0400, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > At Thu, 22 Apr 2021 23:17:19 -0400, Tom Lane wrote in
> >> Doesn't seem like a good idea, because that locks us into an assumption
> >> that the downcasing conversion doesn't change the string's phys
Kyotaro Horiguchi writes:
> At Thu, 22 Apr 2021 23:17:19 -0400, Tom Lane wrote in
>> Doesn't seem like a good idea, because that locks us into an assumption
>> that the downcasing conversion doesn't change the string's physical
>> length. There are a lot of counterexamples to that :-(. I'm not
At Thu, 22 Apr 2021 23:17:19 -0400, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > All usages of pg_string_tolower don't need a copy.
> > So don't we change the function to in-place converter?
>
> Doesn't seem like a good idea, because that locks us into an assumption
> that the downcasing c
At Fri, 23 Apr 2021 11:58:12 +0900 (JST), Kyotaro Horiguchi
wrote in
> > Any further comment is very welcome.
Oh, I accidentally found a doubious behsbior.
=# alter table public.
public.c1public.d1public."t" public.t public."tt"
The "t" and "tt" are needlessly lower-cased.
#
Kyotaro Horiguchi writes:
> All usages of pg_string_tolower don't need a copy.
> So don't we change the function to in-place converter?
Doesn't seem like a good idea, because that locks us into an assumption
that the downcasing conversion doesn't change the string's physical
length. There are a
At Thu, 22 Apr 2021 12:43:42 +, "tanghy.f...@fujitsu.com"
wrote in
> On Wednesday, April 21, 2021 1:24 PM, Peter Smith
> Wrot> >4. Memory not freed in multiple places?
> oops. Memory free added.
All usages of pg_string_tolower don't need a copy.
So don't we change the function to in-place
On Wednesday, April 21, 2021 1:24 PM, Peter Smith Wrote
>I tried playing a bit with your psql patch V5 and I did not find any
>problems - it seemed to work as advertised.
>
>Below are a few code review comments.
Thanks for you review. I've updated the patch to V6 according to your comments.
>1.
On Wed, Apr 14, 2021 at 11:34 PM tanghy.f...@fujitsu.com
wrote:
>
> On Thursday, April 8, 2021 4:14 PM, Peter Eisentraut
> wrote
>
> >Seeing the tests you provided, it's pretty obvious that the current
> >behavior is insufficient. I think we could probably think of a few more
> >tests, for exam
On Thursday, April 8, 2021 4:14 PM, Peter Eisentraut
wrote
>Seeing the tests you provided, it's pretty obvious that the current
>behavior is insufficient. I think we could probably think of a few more
>tests, for example exercising the "If case insensitive matching was
>requested initially,
On 01.04.21 11:40, tanghy.f...@fujitsu.com wrote:
On Wednesday, March 31, 2021 4:05 AM, David Zhang wrote
8 postgres=# update tbl SET DATA =
9
10 postgres=# update TBL SET
11
12 postgres=#
So, as you can see the difference is between line 8 and 10 in case 2. It
looks like the lowe
On Wednesday, March 31, 2021 4:05 AM, David Zhang wrote
> 8 postgres=# update tbl SET DATA =
> 9
> 10 postgres=# update TBL SET
> 11
> 12 postgres=#
>
>So, as you can see the difference is between line 8 and 10 in case 2. It
>looks like the lowercase can auto complete more than the upperc
Hi Tang,
Thanks a lot for the patch.
I did a quick test based on the latest patch V3 on latest master branch
"commit 4753ef37e0eda4ba0af614022d18fcbc5a946cc9".
Case 1: before patch
1 postgres=# set a
2 all allow_system_table_mods
application_name array_nulls
On Tuesday, March 16, 2021 5:20 AM, Peter Eisentraut
wrote:
>The cases that complete with a query
>result are not case insensitive right now. This affects things like
>
>UPDATE T
>
>as well. I think your first patch was basically right. But we need to
>understand that this affects all com
On 09.02.21 15:48, Tang, Haiying wrote:
I'm still confused about the APPROPRIATE behavior of tab completion.
It seems ALTER table/tablespace SET/RESET is already case-insensitive.
For example
# alter tablespace dbspace set(e[tab]
# alter tablespace dbspace set(effective_io_concurrency
# alter
At Sun, 07 Feb 2021 13:55:00 -0500, Tom Lane wrote in
>
> This looks like you're trying to force case-insensitive behavior
> whether that is appropriate or not. Does not sound like a good idea.
I'm still confused about the APPROPRIATE behavior of tab completion.
It seems ALTER table/tablespace
the case of SET/RESET commands).
Thanks for your update. I applied your patch, it works well for SET/RESET
commands.
I added the same modification to SHOW command. The new patch(V2) can support
tab completion for upper character inputs in psql for SET/RESET/SHOW commands.
Regards,
Tang
V2-0001-Su
At Sun, 07 Feb 2021 13:55:00 -0500, Tom Lane wrote in
> "Tang, Haiying" writes:
> > When using psql I found there's no tab completion for upper character
> > inputs. It's really inconvenient sometimes so I try to fix this problem in
> > the attached patch.
>
> This looks like you're trying to
"Tang, Haiying" writes:
> When using psql I found there's no tab completion for upper character inputs.
> It's really inconvenient sometimes so I try to fix this problem in the
> attached patch.
This looks like you're trying to force case-insensitive behavior
whether that is appropriate or not.
Hi Hackers,
When using psql I found there's no tab completion for upper character inputs.
It's really inconvenient sometimes so I try to fix this problem in the attached
patch.
Here is the examples to show what this patch can do.
Action:
1. connect the db using psql
2. input SQL command
3. en
51 matches
Mail list logo
