Re: [HACKERS] [PATCH] Generic type subscripting

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Steele <david(at)pgmasters(dot)net>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] [PATCH] Generic type subscripting
Date: 2020-09-16 11:52:27
Message-ID: CAFj8pRDWShrKjNs7Q1u=ZDT4jKpXQfVwfy-kA6K_JXtRF8MoYg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

st 16. 9. 2020 v 11:36 odesílatel Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
napsal:

> > st 9. 9. 2020 v 23:04 Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> >
> > This seems to already hit a merge conflict (8febfd185).
> > Would you re-rebase ?
>
> Thanks. Sure, will post a rebased version soon.
>
> > On Tue, Sep 15, 2020 at 08:42:40PM +0200, Pavel Stehule wrote:
> >
> > Maybe I found a another issue.
> >
> > create table foo(a jsonb);
> >
> > postgres=# select * from foo;
> > ┌───────────────────────────────────────────────────────────────────┐
> > │ a │
> > ╞═══════════════════════════════════════════════════════════════════╡
> > │ [0, null, null, null, null, null, null, null, null, null, "ahoj"] │
> > └───────────────────────────────────────────────────────────────────┘
> > (1 row)
> >
> > It is working like I expect
> >
> > but
> >
> > postgres=# truncate foo;
> > TRUNCATE TABLE
> > postgres=# insert into foo values('[]');
> > INSERT 0 1
> > postgres=# update foo set a[10] = 'ahoj';
> > UPDATE 1
> > postgres=# select * from foo;
> > ┌──────────┐
> > │ a │
> > ╞══════════╡
> > │ ["ahoj"] │
> > └──────────┘
> > (1 row)
>
> Thanks for looking at the last patch, I appreciate! The situation you've
> mention is an interesting edge case. If I understand correctly, the
> first example is the result of some operations leading to filling gaps
> between 0 and "ahoj". In the second case there is no such gap that's why
> nothing was "filled in", although one could expect presence of a "start
> position" and fill with nulls everything from it to the new element, is
> that what you mean?
>

I expect any time

a[10] := 10;

? a[10] --> 10

===

postgres=# truncate foo;
TRUNCATE TABLE
postgres=# insert into foo values('[]');
INSERT 0 1
postgres=# update foo set a[10] = 'AHOJ';
UPDATE 1
postgres=# select (a)[10] from foo;
┌───┐
│ a │
╞═══╡
│ ∅ │
└───┘
(1 row)

There should be consistency

postgres=# create table foo2(a text[]);
CREATE TABLE
postgres=# insert into foo2 values('{}');
INSERT 0 1
postgres=# update foo set a[10] = 'AHOJ';
UPDATE 1
postgres=# select (a)[10] from foo;
┌────────┐
│ a │
╞════════╡
│ "AHOJ" │
└────────┘
(1 row)

and some natural behaviour - any special case with different behaviour is a
bad thing generally.

Regards

Pavel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2020-09-16 12:33:57 Re: PostgreSQL 13 RC 1 release announcement draft
Previous Message Asim Praveen 2020-09-16 11:43:14 Re: Parallelize stream replication process