Re: Some questions about the array.

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Uriy Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Some questions about the array.
Date: 2015-12-22 07:21:31
Message-ID: CAB7nPqQ+hx4t4uq1y8FHkyicRD9NgkJHo2HKSSp1yRXKPuLOag@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 22, 2015 at 2:28 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Uriy Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru> writes:
>>> I'm dubious that the parsetree representation is well-chosen.
>>> Probably a single is_slice flag would have been better.
>
>> What do you mean? This flag is for what? You are about the A_Indices
>> node(lidx_default/uidx_default)?
>
> Yes. Those flags are partially redundant with the subtree pointers being
> NULL, and there are combinations that would be invalid (such as
> lidx_default being set but lidx not being null), and it's pretty unobvious
> what the difference in representation is between a non-slice case and a
> slice case with only the upper index provided. In fact, since you have
> five syntaxes to represent, it's impossible for the two bools to
> distinguish them all, which means that at least one case *must* be
> identified by null-ness of a pointer contradicting what the corresponding
> bool's setting would imply. So this just seems like a mess to me.
>
> I think it would come out cleaner if you had just one bool is_slice,
> which corresponds directly to whether a colon was present. The four
> sub-possibilities of colon notation would be represented by combinations
> of null and non-null lidx and uidx. With is_slice false, the only valid
> case is lidx==NULL, uidx!=NULL, as before for non-slice notation.

Patch is still in the works and author is still active, so moved to next CF.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2015-12-22 08:18:01 Re: A typo in syncrep.c
Previous Message Michael Paquier 2015-12-22 07:17:59 Re: pglogical_output - a general purpose logical decoding output plugin