Re: Cleaning up array_in()

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Nikhil Benesch <nikhil(dot)benesch(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Cleaning up array_in()
Date: 2023-07-03 04:16:22
Message-ID: CACJufxEnWzzmpSUHg=yrfFeSa7ioa=H_MdBqyoJoA5yJvpHf3g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 5, 2023 at 9:48 AM Nikhil Benesch <nikhil(dot)benesch(at)gmail(dot)com> wrote:
>
> I took a look at 0002 because I attempted a similar but more surgical
> fix in [0].
>
> I spotted a few opportunities for further reducing state tracked by
> `ArrayCount`. You may not find all of these suggestions to be
> worthwhile.

I pull ArrayCount into a separate C function, regress test (manually)
based on patch regress test.

> 1) `in_quotes` appears to be wholly redundant with `parse_state ==
> ARRAY_QUOTED_ELEM_STARTED`.

removing it works as expected.

> 3) `eoArray` could be replaced with a new `ArrayParseState` of
> `ARRAY_END`. Just a matter of taste, but "end of array" feels like a
> parser state to me.

works. (reduce one variable.)

> I also have a sense that `ndims_frozen` made the distinction between
> `ARRAY_ELEM_DELIMITED` and `ARRAY_LEVEL_DELIMITED` unnecessary, and
> the two states could be merged into a single `ARRAY_DELIMITED` state,
> but I've not pulled on this thread hard enough to say so confidently.

merging these states into one work as expected.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-07-03 04:18:42 Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN
Previous Message Amit Kapila 2023-07-03 04:12:42 Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication