Re: [HACKERS] [PATCH] Generic type subscription

Поиск
Список
Период
Сортировка
От Dmitry Dolgov
Тема Re: [HACKERS] [PATCH] Generic type subscription
Дата
Msg-id CA+q6zcWCKUbUwZtC5eK28UZLW_qDegOdyZq3HRMP9M92aeVG=w@mail.gmail.com
обсуждение исходный текст
Ответ на [PATCH] Generic type subscription  (Dmitry Dolgov <9erthalion6@gmail.com>)
Ответы Re: [HACKERS] [PATCH] Generic type subscription  (Artur Zakirov <a.zakirov@postgrespro.ru>)
Список pgsql-hackers
> On 27 December 2016 at 16:09, Aleksander Alekseev <a.alekseev@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 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?

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: [HACKERS] comments tablecmds.c
Следующее
От: 高增琦
Дата:
Сообщение: Re: [HACKERS] Declarative partitioning - another take