[PATCH] Generic type subscripting

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
141 messages Options
1 ... 345678
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Dmitry Dolgov
> On Fri, 12 Oct 2018 at 07:52, Pavel Stehule <[hidden email]> wrote:
>
>> > postgres=# insert into test(v) values( '[]');
>> > INSERT 0 1
>> > postgres=# update test set v[1000] = 'a';
>> > UPDATE 1
>> > postgres=# update test set v[1000] = 'a';
>> > UPDATE 1
>> > postgres=# update test set v[1000] = 'a';
>> > UPDATE 1
>> > postgres=# select * from test;
>> > ┌────┬─────────────────┐
>> > │ id │        v        │
>> > ╞════╪═════════════════╡
>> > │    │ ["a", "a", "a"] │
>> > └────┴─────────────────┘
>> > (1 row)
>> >
>> > It should to raise exception in this case. Current behave allows append simply, but can be source of errors. For this case we can introduce some special symbol - some like -0 :)
>>
>> Yeah, it may look strange, but there is a reason behind it. I tried to keep the
>> behaviour of this feature consistent with jsonb_set function (and in fact
>> they're sharing the same functionality). And for jsonb_set it's documented:
>>
>>     If the item (of a path, in our case an index) is out of the range
>>     -array_length .. array_length -1, and create_missing is true, the new value
>>     is added at the beginning of the array if the item is negative, and at the
>>     end of the array if it is positive.
>>
>> So, the index 1000 is way above the end of the array v, and every new item has
>> being appended at the end.
>>
>> Of course no one said that they should behave similarly, but I believe it's
>> quite nice to have consistency here. Any other opinions?
>
>
> Aha - although I understand to your motivation, I am think so it is bad design - and jsonb_set behave is not happy.
>
> I am think so it is wrong idea, because you lost some information - field position - I push value on index 10, but it will be stored on second position.

The thing is that we don't store the field position in this sense anyway in
jsonb. For arrays there are dimentions, boundaries and null bitmaps stored, but
for jsonb it's just an array of elements. If we want to store this data, we
either have to change the format, or fill in a jsonb with null values up to the
required position (the first option is out of the scope of this patch, the
second doesn't sound that good).

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Pavel Stehule


st 7. 11. 2018 v 16:25 odesílatel Dmitry Dolgov <[hidden email]> napsal:
> On Fri, 12 Oct 2018 at 07:52, Pavel Stehule <[hidden email]> wrote:
>
>> > postgres=# insert into test(v) values( '[]');
>> > INSERT 0 1
>> > postgres=# update test set v[1000] = 'a';
>> > UPDATE 1
>> > postgres=# update test set v[1000] = 'a';
>> > UPDATE 1
>> > postgres=# update test set v[1000] = 'a';
>> > UPDATE 1
>> > postgres=# select * from test;
>> > ┌────┬─────────────────┐
>> > │ id │        v        │
>> > ╞════╪═════════════════╡
>> > │    │ ["a", "a", "a"] │
>> > └────┴─────────────────┘
>> > (1 row)
>> >
>> > It should to raise exception in this case. Current behave allows append simply, but can be source of errors. For this case we can introduce some special symbol - some like -0 :)
>>
>> Yeah, it may look strange, but there is a reason behind it. I tried to keep the
>> behaviour of this feature consistent with jsonb_set function (and in fact
>> they're sharing the same functionality). And for jsonb_set it's documented:
>>
>>     If the item (of a path, in our case an index) is out of the range
>>     -array_length .. array_length -1, and create_missing is true, the new value
>>     is added at the beginning of the array if the item is negative, and at the
>>     end of the array if it is positive.
>>
>> So, the index 1000 is way above the end of the array v, and every new item has
>> being appended at the end.
>>
>> Of course no one said that they should behave similarly, but I believe it's
>> quite nice to have consistency here. Any other opinions?
>
>
> Aha - although I understand to your motivation, I am think so it is bad design - and jsonb_set behave is not happy.
>
> I am think so it is wrong idea, because you lost some information - field position - I push value on index 10, but it will be stored on second position.

The thing is that we don't store the field position in this sense anyway in
jsonb. For arrays there are dimentions, boundaries and null bitmaps stored, but
for jsonb it's just an array of elements. If we want to store this data, we
either have to change the format, or fill in a jsonb with null values up to the
required position (the first option is out of the scope of this patch, the
second doesn't sound that good).

I don't agree. If we use a  same syntax for some objects types, we should to enforce some consistency.

I don't think so you should to introduce nulls for JSONs. In this case, the most correct solution is raising a exception.

Regards

Pavel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Dmitry Dolgov
> On Wed, 7 Nov 2018 at 17:09, Pavel Stehule <[hidden email]> wrote:
>
> I don't agree. If we use a  same syntax for some objects types, we should to enforce some consistency.

Just to make it clear, consistency between what?

> I don't think so you should to introduce nulls for JSONs. In this case, the most correct solution is raising a exception.

Now it's my turn to disagree. As an argument I have this thread [1], where
similar discussion happened about flexibility of jsonb and throwing an errors
(in this particular case whether or not to throw an error when a non existing
path was given to jsonb_set).

I can imagine significant number of use cases when adding a value to jsonb like
that is desirable outcome, and I'm not sure if I can come up with an example
when strictness is the best result. Maybe if you have something in mind, you
can describe what would be the case for that? Also as I've mentioned before,
consistency between jsonb_set and jsonb subscripting operator will help us to
avoid tons of question about why I can do this and this using one option, but
not another.

[1]: https://www.postgresql.org/message-id/CAM3SWZT3uZ7aFktx-nNEWGbapN1oy2t2gt10pnOzygZys_Ak1Q%40mail.gmail.com

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Pavel Stehule


st 7. 11. 2018 v 19:35 odesílatel Dmitry Dolgov <[hidden email]> napsal:
> On Wed, 7 Nov 2018 at 17:09, Pavel Stehule <[hidden email]> wrote:
>
> I don't agree. If we use a  same syntax for some objects types, we should to enforce some consistency.

Just to make it clear, consistency between what?

> I don't think so you should to introduce nulls for JSONs. In this case, the most correct solution is raising a exception.

Now it's my turn to disagree. As an argument I have this thread [1], where
similar discussion happened about flexibility of jsonb and throwing an errors
(in this particular case whether or not to throw an error when a non existing
path was given to jsonb_set).

It doesn't mean so it is designed well.

I can imagine significant number of use cases when adding a value to jsonb like
that is desirable outcome, and I'm not sure if I can come up with an example
when strictness is the best result. Maybe if you have something in mind, you
can describe what would be the case for that? Also as I've mentioned before,
consistency between jsonb_set and jsonb subscripting operator will help us to
avoid tons of question about why I can do this and this using one option, but
not another.

I have only one argument - with this behave nobody knows if value was appended or updated.


 

[1]: https://www.postgresql.org/message-id/CAM3SWZT3uZ7aFktx-nNEWGbapN1oy2t2gt10pnOzygZys_Ak1Q%40mail.gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Dmitry Dolgov
> On Thu, 8 Nov 2018 at 06:14, Pavel Stehule <[hidden email]> wrote:
>
>> Now it's my turn to disagree. As an argument I have this thread [1], where
>> similar discussion happened about flexibility of jsonb and throwing an errors
>> (in this particular case whether or not to throw an error when a non existing
>> path was given to jsonb_set).
>
> It doesn't mean so it is designed well.
>>
>> I can imagine significant number of use cases when adding a value to jsonb like
>> that is desirable outcome, and I'm not sure if I can come up with an example
>> when strictness is the best result. Maybe if you have something in mind, you
>> can describe what would be the case for that? Also as I've mentioned before,
>> consistency between jsonb_set and jsonb subscripting operator will help us to
>> avoid tons of question about why I can do this and this using one option, but
>> not another.
>
> I have only one argument - with this behave nobody knows if value was appended or updated.

Well, maybe you're right, and I would love to discuss our approach to modify
jsonb values, but the point is that the purpose of this patch is to
provide a new
"friendly" syntax to do so, not to change how it works or provide an
alternative version of update functionality.

Even if you'll convince me that subscripting for jsonb now should behave
differently from jsonb_set, I would suggest to do this within a separate patch
set, since the current one is already too big (probably that's why the review
process is so slow).

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Dmitry Dolgov
> On Thu, 8 Nov 2018 at 16:19, Dmitry Dolgov <[hidden email]> wrote:

>
> > On Thu, 8 Nov 2018 at 06:14, Pavel Stehule <[hidden email]> wrote:
> >
> >> Now it's my turn to disagree. As an argument I have this thread [1], where
> >> similar discussion happened about flexibility of jsonb and throwing an errors
> >> (in this particular case whether or not to throw an error when a non existing
> >> path was given to jsonb_set).
> >
> > It doesn't mean so it is designed well.
> >>
> >> I can imagine significant number of use cases when adding a value to jsonb like
> >> that is desirable outcome, and I'm not sure if I can come up with an example
> >> when strictness is the best result. Maybe if you have something in mind, you
> >> can describe what would be the case for that? Also as I've mentioned before,
> >> consistency between jsonb_set and jsonb subscripting operator will help us to
> >> avoid tons of question about why I can do this and this using one option, but
> >> not another.
> >
> > I have only one argument - with this behave nobody knows if value was appended or updated.
>
> Well, maybe you're right, and I would love to discuss our approach to modify
> jsonb values, but the point is that the purpose of this patch is to
> provide a new
> "friendly" syntax to do so, not to change how it works or provide an
> alternative version of update functionality.
>
> Even if you'll convince me that subscripting for jsonb now should behave
> differently from jsonb_set, I would suggest to do this within a separate patch
> set, since the current one is already too big (probably that's why the review
> process is so slow).
I've noticed, that patch has some conflicts, so here is the rebased version.
Also, since people are concern about performance impact for arrays, I've done
some tests similar to [1], but agains the current master - results are similar
so far, I've got quite insignificant difference between the master and the
patched version.

[1]: https://www.postgresql.org/message-id/CA%2Bq6zcV8YCKcMHkUKiiUM3eOsq-ubb%3DT1D%2Bki4YbE%3DBYbt1PxQ%40mail.gmail.com

0005-Subscripting-documentation-v14.patch (26K) Download Attachment
0003-Subscripting-for-array-v14.patch (18K) Download Attachment
0002-Base-implementation-of-subscripting-mechanism-v14.patch (85K) Download Attachment
0001-Renaming-for-new-subscripting-mechanism-v14.patch (74K) Download Attachment
0004-Subscripting-for-jsonb-v14.patch (45K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Dmitry Dolgov
> On Fri, Nov 9, 2018 at 1:55 PM Dmitry Dolgov <[hidden email]> wrote:
>
> I've noticed, that patch has some conflicts, so here is the rebased version.
> Also, since people are concern about performance impact for arrays, I've done
> some tests similar to [1], but agains the current master - results are similar
> so far, I've got quite insignificant difference between the master and the
> patched version.
>
> [1]: https://www.postgresql.org/message-id/CA%2Bq6zcV8YCKcMHkUKiiUM3eOsq-ubb%3DT1D%2Bki4YbE%3DBYbt1PxQ%40mail.gmail.com

One more rebased version. This time I also decided to use this opportunity, to
write more descriptive commit messages.

0001-Renaming-for-new-subscripting-mechanism-v15.patch (75K) Download Attachment
0002-Base-implementation-of-subscripting-mechanism-v15.patch (86K) Download Attachment
0003-Subscripting-for-array-v15.patch (18K) Download Attachment
0005-Subscripting-documentation-v15.patch (27K) Download Attachment
0004-Subscripting-for-jsonb-v15.patch (45K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Thomas Munro-3
On Mon, Nov 26, 2018 at 6:07 AM Dmitry Dolgov <[hidden email]> wrote:

> > On Fri, Nov 9, 2018 at 1:55 PM Dmitry Dolgov <[hidden email]> wrote:
> >
> > I've noticed, that patch has some conflicts, so here is the rebased version.
> > Also, since people are concern about performance impact for arrays, I've done
> > some tests similar to [1], but agains the current master - results are similar
> > so far, I've got quite insignificant difference between the master and the
> > patched version.
> >
> > [1]: https://www.postgresql.org/message-id/CA%2Bq6zcV8YCKcMHkUKiiUM3eOsq-ubb%3DT1D%2Bki4YbE%3DBYbt1PxQ%40mail.gmail.com
>
> One more rebased version. This time I also decided to use this opportunity, to
> write more descriptive commit messages.

Hi Dmitry,

Noticed on cfbot.cputube.org:

pg_type.c:167:10: error: passing argument 3 of
‘GenerateTypeDependencies’ makes integer from pointer without a cast
[-Werror]
false);
^
In file included from pg_type.c:28:0:
../../../src/include/catalog/pg_type.h:335:13: note: expected ‘Oid’
but argument is of type ‘void *’
extern void GenerateTypeDependencies(Oid typeObjectId,
^

--
Thomas Munro
http://www.enterprisedb.com

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Dmitry Dolgov
> On Sun, Nov 25, 2018 at 9:31 PM Thomas Munro <[hidden email]> wrote:
>
> Noticed on cfbot.cputube.org:
>
> pg_type.c:167:10: error: passing argument 3 of
> ‘GenerateTypeDependencies’ makes integer from pointer without a cast
> [-Werror]
> false);

Thanks for noticing! I was in rush when did rebase, and made few mistakes (the
moral of the story - do not rush). Here is the fix, which is more aligned with
the commit ab69ea9fee.

0005-Subscripting-documentation-v16.patch (27K) Download Attachment
0004-Subscripting-for-jsonb-v16.patch (45K) Download Attachment
0002-Base-implementation-of-subscripting-mechanism-v16.patch (85K) Download Attachment
0003-Subscripting-for-array-v16.patch (18K) Download Attachment
0001-Renaming-for-new-subscripting-mechanism-v16.patch (75K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Dmitry Dolgov
> On Mon, Nov 26, 2018 at 1:37 PM Dmitry Dolgov <[hidden email]> wrote:
>
> Thanks for noticing! I was in rush when did rebase, and made few mistakes (the
> moral of the story - do not rush). Here is the fix, which is more aligned with
> the commit ab69ea9fee.

And one more rebase with pretty much the same functionality so far.

0001-Renaming-for-new-subscripting-mechanism-v17.patch (75K) Download Attachment
0005-Subscripting-documentation-v17.patch (27K) Download Attachment
0003-Subscripting-for-array-v17.patch (18K) Download Attachment
0004-Subscripting-for-jsonb-v17.patch (45K) Download Attachment
0002-Base-implementation-of-subscripting-mechanism-v17.patch (85K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Alvaro Herrera-9
Would anybody object to me pushing part 0001 soon?  It seems pointless
to force Dmitry keep rebasing a huge renaming patch all this time.  I
think the general feeling is that this is a desirable change, so let's
keep things moving.

That having been said ... while the current 0001 patch does apply
semi-cleanly (`git apply -3` does it), it does not compile, probably
because of header refactoring.  Please rebase and make sure that each
individual patch compiles cleanly.

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Pavel Stehule


čt 31. 1. 2019 v 16:39 odesílatel Alvaro Herrera <[hidden email]> napsal:
Would anybody object to me pushing part 0001 soon?  It seems pointless
to force Dmitry keep rebasing a huge renaming patch all this time.  I
think the general feeling is that this is a desirable change, so let's
keep things moving.

That having been said ... while the current 0001 patch does apply
semi-cleanly (`git apply -3` does it), it does not compile, probably
because of header refactoring.  Please rebase and make sure that each
individual patch compiles cleanly.

+1

Pavel

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Dmitry Dolgov
In reply to this post by Alvaro Herrera-9
> On Thu, Jan 31, 2019 at 4:39 PM Alvaro Herrera <[hidden email]> wrote:
>
> That having been said ... while the current 0001 patch does apply
> semi-cleanly (`git apply -3` does it), it does not compile, probably
> because of header refactoring.  Please rebase and make sure that each
> individual patch compiles cleanly.

Oh, sorry for that, I'll fix it in a moment.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Dmitry Dolgov
In reply to this post by Pavel Stehule
> On Thu, Jan 31, 2019 at 4:43 PM Pavel Stehule <[hidden email]> wrote:

>
> čt 31. 1. 2019 v 16:39 odesílatel Alvaro Herrera <[hidden email]> napsal:
>>
>> Would anybody object to me pushing part 0001 soon?  It seems pointless
>> to force Dmitry keep rebasing a huge renaming patch all this time.  I
>> think the general feeling is that this is a desirable change, so let's
>> keep things moving.
>>
>> That having been said ... while the current 0001 patch does apply
>> semi-cleanly (`git apply -3` does it), it does not compile, probably
>> because of header refactoring.  Please rebase and make sure that each
>> individual patch compiles cleanly.
>
> +1

> On Thu, Jan 31, 2019 at 4:45 PM Dmitry Dolgov <[hidden email]> wrote:
> Oh, sorry for that, I'll fix it in a moment.

The moment was longer than I expected, but here is the rebased version, where
all the individual patches can be applied and compiled cleanly (although there
is still functional dependency between 0002 and 0003, since the former
introduces a new subscripting without any implementation, and the latter
introduces an implementation for array data type).

0003-Subscripting-for-array-v18.patch (33K) Download Attachment
0001-Renaming-for-new-subscripting-mechanism-v18.patch (112K) Download Attachment
0005-Subscripting-documentation-v18.patch (27K) Download Attachment
0004-Subscripting-for-jsonb-v18.patch (45K) Download Attachment
0002-Base-implementation-of-subscripting-mechanism-v18.patch (65K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Alvaro Herrera-9
I think it's worth pointing out that "git format-patch -v" exists :-)

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Alvaro Herrera-9
On 2019-Feb-01, Alvaro Herrera wrote:

> I think it's worth pointing out that "git format-patch -v" exists :-)

... and you're going to need "git format-patch -v19", because contrib
doesn't build with 18.

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Alvaro Herrera-9
On 2019-Feb-01, Alvaro Herrera wrote:

> On 2019-Feb-01, Alvaro Herrera wrote:
>
> > I think it's worth pointing out that "git format-patch -v" exists :-)
>
> ... and you're going to need "git format-patch -v19", because contrib
> doesn't build with 18.

And that suggests that maybe we should keep the old names working, to
avoid breaking every extension out there that deals with ArrayRef,
though I'm not sure if after patches 0002 ff it'll be possible to keep
them working without changes.

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Dmitry Dolgov
> On Fri, Feb 1, 2019 at 12:54 PM Alvaro Herrera <[hidden email]> wrote:
>
> On 2019-Feb-01, Alvaro Herrera wrote:
>
> > On 2019-Feb-01, Alvaro Herrera wrote:
> >
> > ... and you're going to need "git format-patch -v19", because contrib
> > doesn't build with 18.
>
> And that suggests that maybe we should keep the old names working, to
> avoid breaking every extension out there that deals with ArrayRef,
> though I'm not sure if after patches 0002 ff it'll be possible to keep
> them working without changes.

Can you please point out for me what exactly doesn't build? I just tried to
build contrib and ran all the tests, everything finished succesfully, which is
also confirmed by bot [1].

> I think it's worth pointing out that "git format-patch -v" exists :-)

Fortunately, I know. But yeah, no idea why I started to add a version number at
the end of patch name :)

[1]: https://travis-ci.org/postgresql-cfbot/postgresql/builds/487401077

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Alvaro Herrera-9
On 2019-Feb-01, Dmitry Dolgov wrote:

> Can you please point out for me what exactly doesn't build? I just tried to
> build contrib and ran all the tests, everything finished succesfully, which is
> also confirmed by bot [1].

Well, this is strange: I removed the changes then re-applied the diff,
and it worked fine this time.  Strange.  I can only offer my terminal
log, where it's obvious that the contrib changes were not applied by
"git apply" (even though it did finish successfully):

alvin: src 141$ git apply /tmp/0001-Renaming-for-new-subscripting-mechanism-v18.patch
alvin: src 0$ runpg head install
building heads/master ...
/pgsql/source/master/contrib/pg_stat_statements/pg_stat_statements.c: In function 'JumbleExpr':
/pgsql/source/master/contrib/pg_stat_statements/pg_stat_statements.c:2582:8: error: 'T_ArrayRef' undeclared (first use in this function)
   case T_ArrayRef:
        ^~~~~~~~~~
/pgsql/source/master/contrib/pg_stat_statements/pg_stat_statements.c:2582:8: note: each undeclared identifier is reported only once for each function it appears in
/pgsql/source/master/contrib/pg_stat_statements/pg_stat_statements.c:2584:5: error: unknown type name 'ArrayRef'
     ArrayRef   *aref = (ArrayRef *) node;
     ^~~~~~~~
/pgsql/source/master/contrib/pg_stat_statements/pg_stat_statements.c:2584:25: error: 'ArrayRef' undeclared (first use in this function)
     ArrayRef   *aref = (ArrayRef *) node;
                         ^~~~~~~~
/pgsql/source/master/contrib/pg_stat_statements/pg_stat_statements.c:2584:35: error: expected expression before ')' token
     ArrayRef   *aref = (ArrayRef *) node;
                                   ^
/pgsql/source/master/contrib/pg_stat_statements/pg_stat_statements.c:2586:37: error: request for member 'refupperindexpr' in something not a structure or union
     JumbleExpr(jstate, (Node *) aref->refupperindexpr);
                                     ^~
/pgsql/source/master/contrib/pg_stat_statements/pg_stat_statements.c:2587:37: error: request for member 'reflowerindexpr' in something not a structure or union
     JumbleExpr(jstate, (Node *) aref->reflowerindexpr);
                                     ^~
/pgsql/source/master/contrib/pg_stat_statements/pg_stat_statements.c:2588:37: error: request for member 'refexpr' in something not a structure or union
     JumbleExpr(jstate, (Node *) aref->refexpr);
                                     ^~
/pgsql/source/master/contrib/pg_stat_statements/pg_stat_statements.c:2589:37: error: request for member 'refassgnexpr' in something not a structure or union
     JumbleExpr(jstate, (Node *) aref->refassgnexpr);
                                     ^~
make[1]: *** [pg_stat_statements.o] Error 1
make[1]: Target 'install' not remade because of errors.
make: *** [install-pg_stat_statements-recurse] Error 2
/pgsql/source/master/contrib/postgres_fdw/deparse.c:152:29: error: unknown type name 'ArrayRef'
 static void deparseArrayRef(ArrayRef *node, deparse_expr_cxt *context);
                             ^~~~~~~~
/pgsql/source/master/contrib/postgres_fdw/deparse.c: In function 'foreign_expr_walker':
/pgsql/source/master/contrib/postgres_fdw/deparse.c:404:8: error: 'T_ArrayRef' undeclared (fir   case T_ArrayRef:
        ^~~~~~~~~~
/pgsql/source/master/contrib/postgres_fdw/deparse.c:404:8: note: each undeclared identifier is reported only once for each function it appears in
/pgsql/source/master/contrib/postgres_fdw/deparse.c:406:5: error: unknown type name 'ArrayRef'
     ArrayRef   *ar = (ArrayRef *) node;
     ^~~~~~~~
/pgsql/source/master/contrib/postgres_fdw/deparse.c:406:23: error: 'ArrayRef' undeclared (first use in this function)
     ArrayRef   *ar = (ArrayRef *) node;
                       ^~~~~~~~
/pgsql/source/master/contrib/postgres_fdw/deparse.c:406:33: error: expected expression before ')' token
     ArrayRef   *ar = (ArrayRef *) node;
                                 ^
/pgsql/source/master/contrib/postgres_fdw/deparse.c:409:11: error: request for member 'refassgnexpr' in something not a structure or union
     if (ar->refassgnexpr != NULL)
           ^~
/pgsql/source/master/contrib/postgres_fdw/deparse.c:417:41: error: request for member 'refupperindexpr' in something not a structure or union
     if (!foreign_expr_walker((Node *) ar->refupperindexpr,
                                         ^~
/pgsql/source/master/contrib/postgres_fdw/deparse.c:420:41: error: request for member 'reflowerindexpr' in something not a structure or union
     if (!foreign_expr_walker((Node *) ar->reflowerindexpr,
                                         ^~
/pgsql/source/master/contrib/postgres_fdw/deparse.c:423:41: error: request for member 'refexpr' in something not a structure or union
     if (!foreign_expr_walker((Node *) ar->refexpr,
                                         ^~
/pgsql/source/master/contrib/postgres_fdw/deparse.c:431:19: error: request for member 'refcollid' in something not a structure or union
     collation = ar->refcollid;
                   ^~
/pgsql/source/master/contrib/postgres_fdw/deparse.c: In function 'deparseExpr':
/pgsql/source/master/contrib/postgres_fdw/deparse.c:2273:8: error: 'T_ArrayRef' undeclared (first use in this function)
   case T_ArrayRef:
        ^~~~~~~~~~
/pgsql/source/master/contrib/postgres_fdw/deparse.c:2274:4: warning: implicit declaration of function 'deparseArrayRef' [-Wimplicit-function-declaration]
    deparseArrayRef((ArrayRef *) node, context);
    ^~~~~~~~~~~~~~~
/pgsql/source/master/contrib/postgres_fdw/deparse.c:2274:21: error: 'ArrayRef' undeclared (first use in this function)
    deparseArrayRef((ArrayRef *) node, context);
                     ^~~~~~~~
/pgsql/source/master/contrib/postgres_fdw/deparse.c:2274:31: error: expected expression before ')' token
    deparseArrayRef((ArrayRef *) node, context);
                               ^
/pgsql/source/master/contrib/postgres_fdw/deparse.c: At top level:
/pgsql/source/master/contrib/postgres_fdw/deparse.c:2524:17: error: unknown type name 'ArrayRef'
 deparseArrayRef(ArrayRef *node, deparse_expr_cxt *context)
                 ^~~~~~~~
make[1]: *** [deparse.o] Error 1
make[1]: Target 'install' not remade because of errors.
make: *** [install-postgres_fdw-recurse] Error 2
make: Target 'install' not remade because of errors.


--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Generic type subscripting

Alvaro Herrera-9
In reply to this post by Dmitry Dolgov
On 2019-Feb-01, Dmitry Dolgov wrote:

> The moment was longer than I expected, but here is the rebased version, where
> all the individual patches can be applied and compiled cleanly (although there
> is still functional dependency between 0002 and 0003, since the former
> introduces a new subscripting without any implementation, and the latter
> introduces an implementation for array data type).

Cool, pushed 0001.  I'm afraid I included some pgindenting, so you'll
have to rebase again.  Maybe you already know how to do it without
manually rebasing, but if not, a quick trick to avoid rebasing manually
over all those whitespace changes might be to un-apply with "git show |
patch -p1 -R", then apply your original 0001, commit, apply 0002, then
pgindent; if you now do a git diff to the original commit, you should
get an almost clean diff.  Or you could just try to apply with -w.

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

1 ... 345678