Hi,
On Fri, Sep 24, 2021 at 02:33:59PM +0800, Julien Rouhaud wrote:
> On Thu, Sep 23, 2021 at 10:21:20AM -0400, Tom Lane wrote:
> >
> > I do have sympathy for the idea that extensions would like to define
> > their own statement types. I just don't see a practical way to do it
> > in our existin
On Thu, Sep 23, 2021 at 10:21:20AM -0400, Tom Lane wrote:
>
> I do have sympathy for the idea that extensions would like to define
> their own statement types. I just don't see a practical way to do it
> in our existing parser infrastructure. This patch certainly doesn't
> offer that.
Allowing
Julien Rouhaud writes:
> My POC's grammar is only like:
> CREATE HYPOTHETICAL INDEX opt_index_name ON relation_expr '(' index_params ')'
> {
> IndexStmt *n = makeNode(IndexStmt);
> n->idxname = $4;
> n->relation = $6;
> n->accessMethod
On Thu, Sep 23, 2021 at 07:37:27AM +0100, Simon Riggs wrote:
> On Thu, 16 Sept 2021 at 05:33, Julien Rouhaud wrote:
>
> > Would any of that be a reasonable approach?
>
> The way I summarize all of the above is that
> 1) nobody is fundamentally opposed to the idea
> 2) we just need to find real-w
On Thu, 16 Sept 2021 at 05:33, Julien Rouhaud wrote:
> Would any of that be a reasonable approach?
The way I summarize all of the above is that
1) nobody is fundamentally opposed to the idea
2) we just need to find real-world example(s) and show that any
associated in-core patch provides all tha
On Thu, Sep 16, 2021 at 5:40 AM Andres Freund wrote:
>
> > I don't have any better ideas to offer :-( ... but I very much fear
> > that the approach proposed here is a dead end.
>
> I unfortunately don't see a good way forward without changing the way we do
> parsing on a more fundamental level :(
Hi,
On 2021-09-15 16:51:37 -0400, Tom Lane wrote:
> The other problem here is that a simple call-this-instead-of-that
> top-level hook doesn't seem all that useful anyway, because it leaves
> you with the task of duplicating a huge amount of functionality that
> you're then going to make some twea
Andres Freund writes:
> Agreed - it doesn't make sense to me to have a hook that only replaces raw
> parsing, without also hooking into parse-analysis. ISTM that the least a
> patchset going for a parser hook would have to do is to do sufficient
> restructuring so that one could hook together into
Hi,
On 2021-09-15 16:35:53 -0400, Jonah H. Harris wrote:
> On Wed, Sep 15, 2021 at 3:55 PM Andres Freund wrote:
> > On 2021-09-15 12:57:00 -0400, Tom Lane wrote:
> > Agreed - it doesn't make sense to me to have a hook that only replaces raw
> > parsing, without also hooking into parse-analysis. I
On Wed, Sep 15, 2021 at 3:55 PM Andres Freund wrote:
> On 2021-09-15 12:57:00 -0400, Tom Lane wrote:
> > That's not what the patch actually does, though. It only replaces
> > the grammar, not semantic analysis. So you couldn't associate the
> > (+)-decorated WHERE clause with the appropriate jo
Hi,
On 2021-09-15 12:57:00 -0400, Tom Lane wrote:
> That's not what the patch actually does, though. It only replaces
> the grammar, not semantic analysis. So you couldn't associate the
> (+)-decorated WHERE clause with the appropriate join. (And no,
> I will not accept that it's okay to perfor
On Thu, Sep 16, 2021 at 1:23 AM Julien Rouhaud wrote:
>
> On Thu, Sep 16, 2021 at 12:57 AM Tom Lane wrote:
> >
> > > The requirement is that the parser can't leak any
> > > node that the rest of the system doesn't know about, but you can do
> > > what you want inside the parser.
> >
> > That's no
On Thu, Sep 16, 2021 at 12:57 AM Tom Lane wrote:
>
> > The requirement is that the parser can't leak any
> > node that the rest of the system doesn't know about, but you can do
> > what you want inside the parser.
>
> That's not what the patch actually does, though. It only replaces
> the grammar
Julien Rouhaud writes:
> I'm not sure why you couldn't implement an Oracle-style outer join
> with such a hook?
Try it.
> The requirement is that the parser can't leak any
> node that the rest of the system doesn't know about, but you can do
> what you want inside the parser.
That's not what th
On Wed, Sep 15, 2021 at 11:26 PM Tom Lane wrote:
>
> In the case at hand, what's troubling me is that I don't see any
> particular use in merely substituting a new bison grammar, if it
> still has to produce parse trees that the rest of the system will
> understand. Yeah, you could make some very
Jim Mlodgenski writes:
> On Wed, Sep 15, 2021 at 9:25 AM Simon Riggs
> wrote:
>> The general rule has always been that we don't just put hooks in, we
>> always require an in-core use for those hooks. I was reminded of that
>> myself recently.
> That's not historically what has happened. There ar
st 15. 9. 2021 v 16:55 odesÃlatel Julien Rouhaud
napsal:
> On Wed, Sep 15, 2021 at 10:14 PM Jim Mlodgenski wrote:
> >
> > On Wed, Sep 15, 2021 at 9:25 AM Simon Riggs
> > wrote:
> > >
> > > The general rule has always been that we don't just put hooks in, we
> > > always require an in-core use f
On Wed, Sep 15, 2021 at 02:25:17PM +0100, Simon Riggs wrote:
> On Sat, 1 May 2021 at 08:24, Julien Rouhaud wrote:
>
> > Being able to extend core parser has been requested multiple times, and
> > AFAICT
> > all previous attempts were rejected not because this isn't wanted but
> > because
> > th
On Wed, Sep 15, 2021 at 10:14 PM Jim Mlodgenski wrote:
>
> On Wed, Sep 15, 2021 at 9:25 AM Simon Riggs
> wrote:
> >
> > The general rule has always been that we don't just put hooks in, we
> > always require an in-core use for those hooks. I was reminded of that
> > myself recently.
> >
> That's
On Wed, Sep 15, 2021 at 9:25 AM Simon Riggs
wrote:
>
> The general rule has always been that we don't just put hooks in, we
> always require an in-core use for those hooks. I was reminded of that
> myself recently.
>
That's not historically what has happened. There are several hooks with
no in cor
On Sat, 1 May 2021 at 08:24, Julien Rouhaud wrote:
> Being able to extend core parser has been requested multiple times, and AFAICT
> all previous attempts were rejected not because this isn't wanted but because
> the proposed implementations required plugins to reimplement all of the core
> gram
v5 attached, fixing conflict with 639a86e36a (Remove Value node struct)
>From 00644b3ec87c11fa4c4a1215ed79238e1407cd29 Mon Sep 17 00:00:00 2001
From: Julien Rouhaud
Date: Wed, 21 Apr 2021 22:47:18 +0800
Subject: [PATCH v5 1/4] Add a parser_hook hook.
This does nothing but allow third-party plugin
On Thu, Jul 22, 2021 at 03:04:19PM +0800, Julien Rouhaud wrote:
> On Thu, Jul 22, 2021 at 12:01:34PM +0530, vignesh C wrote:
> >
> > 1) CFBOT showed the following compilation errors in windows:
>
> Thanks for looking at it. I'm aware of this issue on windows, but as
> mentioned
> in the thread
On Thu, Jul 22, 2021 at 12:01:34PM +0530, vignesh C wrote:
>
> 1) CFBOT showed the following compilation errors in windows:
Thanks for looking at it. I'm aware of this issue on windows, but as mentioned
in the thread the new contrib is there to demonstrate how the new
infrastructure works. If t
On Sat, Jun 12, 2021 at 1:59 PM Julien Rouhaud wrote:
>
> On Tue, Jun 08, 2021 at 12:16:48PM +0800, Julien Rouhaud wrote:
> > On Sun, Jun 06, 2021 at 02:50:19PM +0800, Julien Rouhaud wrote:
> > > On Sat, May 01, 2021 at 03:24:58PM +0800, Julien Rouhaud wrote:
> > > >
> > > > I'm attaching some POC
On Wed, Jul 7, 2021 at 8:45 PM Jim Mlodgenski wrote:
>
> The test module is very useful to show how to use the hook but it isn't
> very useful to the general user like most other things in contrib. It probably
> fits better in src/test/modules
I agree that it's not useful at all to eventually hav
On Wed, Jul 7, 2021 at 5:26 AM Julien Rouhaud wrote:
>
> Also, if this patch is eventually committed and having some code to
> experience the hook is wanted it would probably be better to have a
> very naive parser (based on a few strcmp() calls or something like
> that) to validate the behavior r
Thanks for the review Jim!
On Wed, Jul 7, 2021 at 3:26 AM Jim Mlodgenski wrote:
>
> On Sat, Jun 12, 2021 at 4:29 AM Julien Rouhaud wrote:
>
> The patches all build properly and pass all regressions tests.
Note that the cfbot reports a compilation error on windows. That's on
the grammar extensi
On Sat, Jun 12, 2021 at 4:29 AM Julien Rouhaud wrote:
> I'd like to propose an alternative approach, which is to allow multiple
> parsers
> to coexist, and let third-party parsers optionally fallback on the core
> parsers. I'm sending this now as a follow-up of [1] and to avoid duplicated
> eff
On Tue, Jun 08, 2021 at 12:16:48PM +0800, Julien Rouhaud wrote:
> On Sun, Jun 06, 2021 at 02:50:19PM +0800, Julien Rouhaud wrote:
> > On Sat, May 01, 2021 at 03:24:58PM +0800, Julien Rouhaud wrote:
> > >
> > > I'm attaching some POC patches that implement this approach to start a
> > > discussion.
On Sun, Jun 06, 2021 at 02:50:19PM +0800, Julien Rouhaud wrote:
> On Sat, May 01, 2021 at 03:24:58PM +0800, Julien Rouhaud wrote:
> >
> > I'm attaching some POC patches that implement this approach to start a
> > discussion.
>
> I just noticed that the cfbot fails with the v1 patch. Attached v2
On Sat, May 01, 2021 at 03:24:58PM +0800, Julien Rouhaud wrote:
>
> I'm attaching some POC patches that implement this approach to start a
> discussion.
I just noticed that the cfbot fails with the v1 patch. Attached v2 that should
fix that.
>From db68ec4dd0f0590db2275f0ca99ec24948983462 Mon Sep
Hi,
Being able to extend core parser has been requested multiple times, and AFAICT
all previous attempts were rejected not because this isn't wanted but because
the proposed implementations required plugins to reimplement all of the core
grammar with their own changes, as bison generated parsers a
33 matches
Mail list logo
