From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
---|---|
To: | Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>, Victor Wagner <vitus(at)wagner(dot)pp(dot)ru>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> |
Subject: | Re: [PATCH] Generic type subscription |
Date: | 2016-12-27 09:42:07 |
Message-ID: | CA+q6zcWCKUbUwZtC5eK28UZLW_qDegOdyZq3HRMP9M92aeVG=w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 27 December 2016 at 16:09, Aleksander Alekseev <
a(dot)alekseev(at)postgrespro(dot)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 PM, Dmitry Dolgov
<9erthalion6(at)gmail(dot)com>
> wrote:
>
> > On 15 November 2016 at 15:03, Aleksander Alekseev <
> a(dot)alekseev(at)postgrespro(dot)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 feedback.
>
> Well, if we're speaking about this particular extension, if I understood
> correctly, it fetches all parse tree nodes from Postgres and generates
code
> using this information. So to avoid compilation problems I believe you
need to
> run `make USE_PGXS=1 genparser` again (it worked for me, I don't see any
> mentions of `ArrayRef`).
>
> But speaking generally, I don't see how we can provide backward
> compatibility for those extensions, who are strongly coupled with
implementation details
> of parsing tree. I mean, in terms of interface it's mostly about to
replace
> `ArrayRef` to `SubscriptingRef`, but I think it's better to do it in the
extension code.
Or is there something else that I missed?
From | Date | Subject | |
---|---|---|---|
Next Message | 高增琦 | 2016-12-27 09:48:11 | Re: Declarative partitioning - another take |
Previous Message | Magnus Hagander | 2016-12-27 09:41:29 | Re: comments tablecmds.c |