On 24 January 2017 at 02:36, Tom Lane wrote:
> It might be possible to get away with having only one pg_type column,
> pointing at the parse-analysis function. That function would generate
> a SubscriptingRef tree node containing the OID of the appropriate
> execution function, which execQual.c
On Sat, Jan 28, 2017 at 2:31 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>> On 24 January 2017 at 02:07, Tom Lane wrote:
>> I took an extremely quick look over the patch
>
> Thank you for the feedback. It took some time for me to think about all
> suggestions and notes.
Okay, I am marking th
> On 24 January 2017 at 02:07, Tom Lane wrote:
> I took an extremely quick look over the patch
Thank you for the feedback. It took some time for me to think about all
suggestions and notes.
> 1. As I mentioned previously, it's a seriously bad idea that ArrayRef
> is used for both array subscript
On Thu, Jan 26, 2017 at 1:38 PM, Tom Lane wrote:
> So I'd really prefer that the functionality
> involve a parser callout, and that would certainly need "internal"
> argument(s).
Thanks, I see now.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Robert Haas writes:
> On Mon, Jan 23, 2017 at 2:07 PM, Tom Lane wrote:
>> Can we arrange to do that differently? I'd prefer something in which the
>> argument and result types are visibly connected to the actual datatypes
>> at hand, for instance
>> array_subscript(anyarray, internal) returns an
On Mon, Jan 23, 2017 at 2:07 PM, Tom Lane wrote:
> Can we arrange to do that differently? I'd prefer something in which the
> argument and result types are visibly connected to the actual datatypes
> at hand, for instance
> array_subscript(anyarray, internal) returns anyelement
>
I wrote:
> BTW, a different approach that might be worth considering is to say that
> the nodetree representation of one of these things *is* a FuncExpr, and
> the new magic thing is just that we invent a new CoercionForm value
> which causes ruleutils.c to print the expression as a subscripting op
On 1/23/17 1:36 PM, Tom Lane wrote:
Is there a way for a function
in an extension to find the OID of one of its sibling functions?
Obviously there's regprocedure (or it's C equivalent), but then you're
stuck re-computing at runtime. I've messed around with that a bit in an
effort to have an e
I wrote:
> ... (If that means
> we use two functions not one per datatype, that's fine with me.)
Actually, after thinking about that a bit more: you've really squeezed
*three* different APIs into one function. Namely, subscript-reference
parse analysis, array subscripting execution, and array ass
Dmitry Dolgov <9erthali...@gmail.com> writes:
> [ generic_type_subscription_v6.patch ]
Not too surprisingly, this doesn't apply anymore in the wake of commit
ea15e1867. Could you rebase? Changes for that should be pretty trivial
I'd expect.
I took an extremely quick look over the patch --- most
> Yes, but it was related to the idea of having `ArrayRef` and `JsonbRef` nodes
> for specific types. Since now there is generic `SubscriptingRef` node, I think
> it should be ok.
Sorry I misunderstood it.
> Just to be clear - as far as I understood, these compilation problems were
> caused not b
> On 4 January 2017 at 18:06, Artur Zakirov
wrote:
> But I'm not convinced about how to distinguish ArrayRef node with new
> SubscriptingRef node.
I'm not sure I understood you correctly. You're talking about having two
nodes
`ArrayRef` and `SubscriptingRef` at the same time for the sake of backw
2016-12-27 14:42 GMT+05:00 Dmitry Dolgov <9erthali...@gmail.com>:
>> On 27 December 2016 at 16:09, Aleksander Alekseev
>> wrote:
>> until it breaks existing extensions.
>
> Hm...I already answered, that I managed to avoid compilation problems for
> this particular extension
> using the `genparser`
> On 27 December 2016 at 16:09, Aleksander Alekseev <
a.aleks...@postgrespro.ru> wrote:
> until it breaks existing extensions.
Hm...I already answered, that I managed to avoid compilation problems for
this particular extension
using the `genparser` command again:
> On Thu, Nov 17, 2016 at 10:56 P
As I mentioned above [1] in my humble opinion this patch is not at all in a
"good shape" until it breaks existing extensions.
[1] http://postgr.es/m/20161115080324.GA5351%40e733.localdomain
On Mon, Dec 26, 2016 at 10:49:30PM +0700, Dmitry Dolgov wrote:
> > On 5 December 2016 at 12:03, Haribabu Ko
2016-12-26 18:49 GMT+03:00 Dmitry Dolgov <9erthali...@gmail.com>:
>> On 5 December 2016 at 12:03, Haribabu Kommi
>> wrote:
>
>> Moved to next CF with "needs review" status.
>
> Looks like we stuck here little bit. Does anyone else have any
> suggestions/improvements, or this patch is in good enoug
> On 5 December 2016 at 12:03, Haribabu Kommi
wrote:
> > Moved to next CF with "needs review" status.
Looks like we stuck here little bit. Does anyone else have any
suggestions/improvements, or this patch is in good enough shape?
On Thu, Nov 17, 2016 at 10:56 PM, Dmitry Dolgov <9erthali...@gmail.com>
wrote:
> > On 15 November 2016 at 15:03, Aleksander Alekseev <
> a.aleks...@postgrespro.ru> wrote:
> > Hello.
> >
> > I took a look on the latest -v4 patch. I would like to note that this
> > patch breaks a backward compatibil
> On 15 November 2016 at 15:03, Aleksander Alekseev <
a.aleks...@postgrespro.ru> wrote:
> Hello.
>
> I took a look on the latest -v4 patch. I would like to note that this
> patch breaks a backward compatibility. For instance sr_plan extension[1]
> stop to compile with errors
Thank you for the feed
Hello.
I took a look on the latest -v4 patch. I would like to note that this
patch breaks a backward compatibility. For instance sr_plan extension[1]
stop to compile with errors like:
```
serialize.c:38:2: error: unknown type name ‘ArrayRef’
JsonbValue *ArrayRef_ser(const ArrayRef *node, JsonbP
Hello,
Do you have an updated version of the patch?
2016-10-18 20:41 GMT+03:00 Dmitry Dolgov <9erthali...@gmail.com>:
>
>
> > The term "subscription" is confusing me
>
> Yes, you're right. "container" is too general I think, so I renamed
> everything
> to "subscripting".
>
There is another occur
Hello,
On 04.10.2016 11:28, Victor Wagner wrote:
Git complains about whitespace in this version of patch:
$ git apply ../generic_type_subscription_v2.patch
../generic_type_subscription_v2.patch:218: tab in indent.
int first;
../generic_type_subscription_v2.patch:219: tab in indent.
On Wed, Oct 5, 2016 at 6:48 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> On 5 October 2016 at 03:00, Oleg Bartunov wrote:
>
>>
>> have you ever run 'make check' ?
>>
>> =
>> 53 of 168 tests failed.
>> =
>>
>>
> Sure, how else could I write te
On 5 October 2016 at 03:00, Oleg Bartunov wrote:
>
> have you ever run 'make check' ?
>
> =
> 53 of 168 tests failed.
> =
>
>
Sure, how else could I write tests for this feature? But right now on my
machine
everything is ok (the same for `make inst
On Sat, Oct 1, 2016 at 12:52 PM, Dmitry Dolgov <9erthali...@gmail.com>
wrote:
> > I've tried to compile this patch with current state of master (commit
> > 51c3e9fade76c12) and found out that, when configured with
> --enable-cassert,
> > it doesn't pass make check.
>
> Thanks for the feedback. Ye
On Sat, 1 Oct 2016 16:52:34 +0700
Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > I've tried to compile this patch with current state of master
> > (commit 51c3e9fade76c12) and found out that, when configured with
> --enable-cassert,
> > it doesn't pass make check.
>
> Thanks for the feedba
On Fri, 9 Sep 2016 18:29:23 +0700
Dmitry Dolgov <9erthali...@gmail.com> wrote:
> Hi,
>
> Regarding to the previous conversations [1], [2], here is a patch
> (with some improvements from Nikita Glukhov) for the generic type
> subscription. It allows
> to define type-specific subscription logic for
On 9/9/16 6:29 AM, Dmitry Dolgov wrote:
Regarding to the previous conversations [1], [2], here is a patch (with some
improvements from Nikita Glukhov) for the generic type subscription.
Awesome! Please make sure to add it to the Commit Fest app.
--
Jim Nasby, Data Architect, Blue Treble Consult
28 matches
Mail list logo