Re: [HACKERS] [PATCH] Generic type subscripting
От | Pavel Stehule |
---|---|
Тема | Re: [HACKERS] [PATCH] Generic type subscripting |
Дата | |
Msg-id | CAFj8pRDuJ8n3tf_kaxd4evp3uKa8h3KA97q4GG5qRDxicbGazg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] Generic type subscripting (Dmitry Dolgov <9erthalion6@gmail.com>) |
Ответы |
Re: [HACKERS] [PATCH] Generic type subscripting
|
Список | pgsql-hackers |
> 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.
Yeah, I see your point. IIRC there is no notion of an arbitrary index in
jsonb array, so it needs to be done within an assignment operation
similar to how the last patch fills the gaps between elements. Taking
into account, that if there are more than one elements in the array, all
the gaps should be filled and the behaviour is already the same as you
described, what needs to be changed is more nulls need to be added
around before the first element depending on the assignment index.
I have my concerns about the performance side of this implementation as
well as how surprising this would be for users, but at the same time the
patch already does something similar and the code change should not be
that big, so why not - I can include this change into the next rebased
version. But it still can cause some confusion as it's not going to work
for negative indices, so
update foo set a[-10] = 1;
and
select a[-10] from foo;
can return different value from what was assigned. Otherwise, if we will
try to fix a[-10] assignment in the same way, it will prepend the array
and a[10] will not return the same value.
What is semantic of negative index? It has clean semantic in C, but in PLpgSQL?
В списке pgsql-hackers по дате отправления: