On Tue, Aug 9, 2022 at 12:14 AM Tom Lane wrote:
>
> I wrote:
> > Ah. It'd help if that complaint said what the command input actually
> > is :-(. But on looking closer, I missed stripping the empty strings
> > that "split" will produce at the ends of the array. I think the
> > attached will do
I wrote:
> Ah. It'd help if that complaint said what the command input actually
> is :-(. But on looking closer, I missed stripping the empty strings
> that "split" will produce at the ends of the array. I think the
> attached will do the trick, and I really do want to get rid of this
> copy of
Amit Kapila writes:
> On Sun, Aug 7, 2022 at 8:19 PM Tom Lane wrote:
>> Meh ... it's not checking the data files themselves. Here's
>> a patch based on the logic for invoking genbki. Completely
>> untested, would somebody try it?
> I tried it on commit a69959fab2 just before the commit
On Sun, Aug 7, 2022 at 8:19 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Wed, Aug 3, 2022 at 7:16 PM Tom Lane wrote:
> >> More likely, we need to add something explicit to Mkvcbuild.pm
> >> for this. I recall that it has stanzas to deal with updating
> >> other autogenerated files; I bet
Amit Kapila writes:
> On Wed, Aug 3, 2022 at 7:16 PM Tom Lane wrote:
>> More likely, we need to add something explicit to Mkvcbuild.pm
>> for this. I recall that it has stanzas to deal with updating
>> other autogenerated files; I bet we either missed that or
>> fat-fingered it for
On Wed, Aug 3, 2022 at 7:16 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > I have a question related to commit 964d01ae90. Today, after getting
> > the latest code, when I compiled it on my windows machine, it lead to
> > a compilation error because the outfuncs.funcs.c was not regenerated.
> >
Amit Kapila writes:
> I have a question related to commit 964d01ae90. Today, after getting
> the latest code, when I compiled it on my windows machine, it lead to
> a compilation error because the outfuncs.funcs.c was not regenerated.
> I did the usual steps which I normally perform after getting
On Wed, Jul 13, 2022 at 12:34 AM Peter Eisentraut
wrote:
>
I have a question related to commit 964d01ae90. Today, after getting
the latest code, when I compiled it on my windows machine, it lead to
a compilation error because the outfuncs.funcs.c was not regenerated.
I did the usual steps which
Just one more thing here ... I really don't like the fact that
gen_node_support.pl's response to unparseable input is to silently
ignore it. That's maybe tolerable outside a node struct, but
I think we need a higher standard inside. I experimented with
promoting the commented-out "warn" to
Peter Eisentraut writes:
> On 11.07.22 19:57, Tom Lane wrote:
>> So at this point I'm rather attracted to the idea of reverting to
>> a manually-maintained NodeTag enum. We know how to avoid ABI
>> breakage with that, and it's not exactly the most painful part
>> of adding a new node type.
>
On 11.07.22 19:57, Tom Lane wrote:
So at this point I'm rather attracted to the idea of reverting to
a manually-maintained NodeTag enum. We know how to avoid ABI
breakage with that, and it's not exactly the most painful part
of adding a new node type.
One of the nicer features is that you now
On 2022-07-11 18:39:44 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'm not entirely sure how well either the existing or the sketch above works
> > when doing a VPATH build using tarball sources, and updating the files.
>
> Seems like an awful lot of effort to avoid having multiple copies
Andres Freund writes:
> I'm not entirely sure how well either the existing or the sketch above works
> when doing a VPATH build using tarball sources, and updating the files.
Seems like an awful lot of effort to avoid having multiple copies
of the file list. I think we should just do what I
Hi,
On 2022-07-11 18:09:15 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I don't think it's worth worrying about this not working reliably for non
> > --enable-depend builds, there's a lot more broken than this.
>
> Well, *I* care about that, and I won't stand for making the
>
Andres Freund writes:
> I don't think it's worth worrying about this not working reliably for non
> --enable-depend builds, there's a lot more broken than this.
Well, *I* care about that, and I won't stand for making the
non-enable-depend case significantly more broken than it is now.
In
Hi,
On 2022-07-11 16:38:05 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-07-11 15:54:22 -0400, Tom Lane wrote:
> >> We can't simply move the file list into gen_node_support.pl, because
> >> (a) the build system has to know about the dependencies involved
>
> > Meson has builtin
I wrote:
> Andres Freund writes:
>> Additionally, I think we've had to add tags to the enum in minor releases
>> before and I'm afraid this now would end up looking even more awkward?
> Peter and I already had a discussion about that upthread --- we figured
> that if there's a way to manually
Andres Freund writes:
> On 2022-07-11 15:54:22 -0400, Tom Lane wrote:
>> We can't simply move the file list into gen_node_support.pl, because
>> (a) the build system has to know about the dependencies involved
> Meson has builtin support for tools like gen_node_support.pl reporting which
> files
Andres Freund writes:
> On 2022-07-11 16:17:28 -0400, Robert Haas wrote:
>> Sorry if I'm being dense, but why do we have to duplicate the list of
>> files instead of having gen_node_support.pl just sort whatever list
>> the build system provides to it?
> Because right now there's two
Hi,
On 2022-07-11 16:17:28 -0400, Robert Haas wrote:
> On Mon, Jul 11, 2022 at 3:54 PM Tom Lane wrote:
> > We can't simply move the file list into gen_node_support.pl, because
> > (a) the build system has to know about the dependencies involved, and
> > (b) gen_node_support.pl wouldn't know what
Hi,
On 2022-07-11 15:54:22 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jul 11, 2022 at 1:57 PM Tom Lane wrote:
> >> More generally, I'm having second thoughts about the wisdom of
> >> auto-generating the NodeTag enum at all. With the current setup,
> >> I am absolutely petrified
On Mon, Jul 11, 2022 at 3:54 PM Tom Lane wrote:
> We can't simply move the file list into gen_node_support.pl, because
> (a) the build system has to know about the dependencies involved, and
> (b) gen_node_support.pl wouldn't know what to do in VPATH situations.
> However, we could have
Andres Freund writes:
> Additionally, I think we've had to add tags to the enum in minor releases
> before and I'm afraid this now would end up looking even more awkward?
Peter and I already had a discussion about that upthread --- we figured
that if there's a way to manually assign a nodetag's
Robert Haas writes:
> On Mon, Jul 11, 2022 at 1:57 PM Tom Lane wrote:
>> More generally, I'm having second thoughts about the wisdom of
>> auto-generating the NodeTag enum at all. With the current setup,
>> I am absolutely petrified about the risk of silent ABI breakage
>> thanks to the enum
Hi,
On 2022-07-11 13:57:38 -0400, Tom Lane wrote:
> More generally, I'm having second thoughts about the wisdom of
> auto-generating the NodeTag enum at all. With the current setup,
> I am absolutely petrified about the risk of silent ABI breakage
> thanks to the enum order changing. In
On Mon, Jul 11, 2022 at 1:57 PM Tom Lane wrote:
> More generally, I'm having second thoughts about the wisdom of
> auto-generating the NodeTag enum at all. With the current setup,
> I am absolutely petrified about the risk of silent ABI breakage
> thanks to the enum order changing. In
I wrote:
>> Andres Freund writes:
>>> I was just rebasing meson ontop of this and was wondering whether the input
>>> filenames were in a particular order:
Pushed a patch to make that a bit less random-looking.
> +1 for sorting alphabetically. I experimented with that and it's a
> really
Hi,
On 2022-07-11 12:07:09 -0400, Tom Lane wrote:
> I wrote:
> > Peter Eisentraut writes:
> >> could not handle type "ScanDirection" in struct "IndexScan" field
> >> "indexorderdir"
>
> > Ah, I see. Still, we could also handle that with
> > push @enum_types, qw(ScanDirection);
>
> I tried that,
I wrote:
> Peter Eisentraut writes:
>> could not handle type "ScanDirection" in struct "IndexScan" field
>> "indexorderdir"
> Ah, I see. Still, we could also handle that with
> push @enum_types, qw(ScanDirection);
I tried that, and it does work. The only other input file we could
get rid of
Peter Eisentraut writes:
> On 11.07.22 01:09, Tom Lane wrote:
>> Andres Freund writes:
> I was just rebasing meson ontop of this and was wondering whether the input
> filenames were in a particular order:
> First, things used by later files need to be found in earlier files. So
> that
Peter Eisentraut writes:
> On 11.07.22 01:09, Tom Lane wrote:
>> The rest could probably be alphabetical. I was also wondering if
>> all of them really need to be read at all --- I'm unclear on what
>> access/sdir.h is contributing, for example.
> could not handle type "ScanDirection" in struct
On 11.07.22 01:09, Tom Lane wrote:
Andres Freund writes:
I was just rebasing meson ontop of this and was wondering whether the input
filenames were in a particular order:
First, things used by later files need to be found in earlier files. So
that constrains the order a bit.
Second, the
Andres Freund writes:
> I was just rebasing meson ontop of this and was wondering whether the input
> filenames were in a particular order:
That annoyed me too. I think it's sensible to list the "main" input
files first, but I'd put them in our traditional pipeline order:
> nodes/nodes.h
Hi,
On 2022-07-09 16:37:22 +0200, Peter Eisentraut wrote:
> On 08.07.22 22:03, Tom Lane wrote:
> > I think this is ready to go (don't forget the catversion bump).
>
> This is done now, after a brief vpath-shaped scare from the buildfarm
> earlier today.
I was just rebasing meson ontop of this
Here's some follow-on patches, as I threatened yesterday.
0001 adds some material to nodes/README in hopes of compensating for
a couple of removed comments.
0002 fixes gen_node_support.pl's rather badly broken error reporting.
As it stands, it always says that an error is on line 1 of the
Peter Eisentraut writes:
> On 08.07.22 22:03, Tom Lane wrote:
>> I think this is ready to go (don't forget the catversion bump).
> This is done now, after a brief vpath-shaped scare from the buildfarm
> earlier today.
Doh ... never occurred to me either to try that :-(
On 08.07.22 22:03, Tom Lane wrote:
I think this is ready to go (don't forget the catversion bump).
This is done now, after a brief vpath-shaped scare from the buildfarm
earlier today.
I wrote:
> 0003 moves the node-level attributes as discussed.
Meh. Just realized that I forgot to adjust the commentary in nodes.h
about where to put node attributes.
Maybe like
- * Attributes can be attached to a node as a whole (the attribute
- * specification must be at the end of the
Alvaro Herrera writes:
> While going over this patch, I noticed that I forgot to add support for
> XidList in copyfuncs.c. OK if I push this soon quickly?
Yeah, go ahead, that part of copyfuncs is still going to be manually
maintained, so we need the fix.
What about equalfuncs etc?
While going over this patch, I noticed that I forgot to add support for
XidList in copyfuncs.c. OK if I push this soon quickly?
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
>From 24185e0421cc1e22f9a78f56d03e4585a142e78e Mon Sep 17 00:00:00 2001
From: Alvaro
On 08.07.22 15:52, Tom Lane wrote:
I'll re-read the patch today, but how open are you to putting the
struct attributes at the top? I'm willing to do the legwork.
I agree near the top would be preferable. I think it would even be
feasible to parse the whole thing if pgindent split it across
Peter Eisentraut writes:
> On 06.07.22 22:46, Tom Lane wrote:
>> ... There is one nasty problem
>> we need a solution to, which is that pgindent is not at all on board
>> with this idea of attaching node attrs to typedefs.
> I have found that putting the attributes at the end of the struct
>
I wrote:
> I have gone through this and made some proposed changes (attached),
> and I think it is almost committable.
I see from the cfbot that it now needs to be taught about RelFileNumber...
regards, tom lane
Peter Eisentraut writes:
> [ v7-0001-Automatically-generate-node-support-functions.patch ]
I have gone through this and made some proposed changes (attached),
and I think it is almost committable. There is one nasty problem
we need a solution to, which is that pgindent is not at all on board
On 06.07.22 02:54, Tom Lane wrote:
It might be enough to invent a struct-level attribute allowing
manual assignment of node tags, ie
typedef struct MyNewNode pg_node_attr(nodetag=466)
where it'd be the programmer's responsibility to pick a nonconflicting
tag number. We'd only ever use that in
The new patch addresses almost all of these issues.
> Also, I share David's upthread allergy to the option names
> "path_hackN" and to documenting those only inside the conversion
> script.
I have given these real names now and documented them with the other
attributes.
> BTW, I think this:
... BTW, I thought of a consideration that we probably need some
answer for. As far as I can see, the patch assigns NodeTag values
sequentially in the order it sees the struct declarations in the
input files; an order that doesn't have a lot to do with our past
practice. The problem with that is
Peter Eisentraut writes:
> [ v6-0001-Automatically-generate-node-support-functions.patch ]
I've now spent some time looking at this fairly carefully, and I think
this is a direction we can pursue, but I'm not yet happy about the
amount of magic knowledge that's embedded in the
On 03.07.22 21:14, Tom Lane wrote:
Peter Eisentraut writes:
Here is a patch that reformats the relevant (and a few more) comments
that way. This has been run through pgindent, so the formatting should
be stable.
Now that that's been pushed, the main patch is of course quite broken.
Are you
Peter Eisentraut writes:
> Here is a patch that reformats the relevant (and a few more) comments
> that way. This has been run through pgindent, so the formatting should
> be stable.
Now that that's been pushed, the main patch is of course quite broken.
Are you working on a rebase?
I looked
On 25.03.22 14:08, Peter Eisentraut wrote:
2. Some of these comment lines have become pretty long after having
added the attribute macro.
e.g.
PlannerInfo *subroot pg_node_attr(readwrite_ignore); /* modified
"root" for planning the subquery;
not printed, too large, not interesting enough
On 2022-May-04, Peter Eisentraut wrote:
> I have committed your change to the JsonTableColumnType enum and the removal
> of JsonPathSpec.
Thanks!
> Other than that and some whitespace changes, I didn't find anything in
> your 0002 patch that was different from my last submitted patch. Did
> I
On 19.04.22 13:40, Alvaro Herrera wrote:
I rebased this mostly out of curiousity. I fixed some smallish
conflicts and fixed a typedef problem new in JSON support; however, even
with these fixes it doesn't compile, because JsonPathSpec uses a novel
typedef pattern that apparently will need
On 19.04.22 16:39, Tom Lane wrote:
Maybe we should fix JsonPathSpec to be less creative while we
still can? It's not real clear to me why that typedef even exists,
rather than using a String node, or just a plain char * field.
Yeah, let's get rid of it and use char *.
I see in JsonCommon a
Alvaro Herrera writes:
> I rebased this mostly out of curiousity. I fixed some smallish
> conflicts and fixed a typedef problem new in JSON support; however, even
> with these fixes it doesn't compile, because JsonPathSpec uses a novel
> typedef pattern that apparently will need bespoke handling
I rebased this mostly out of curiousity. I fixed some smallish
conflicts and fixed a typedef problem new in JSON support; however, even
with these fixes it doesn't compile, because JsonPathSpec uses a novel
typedef pattern that apparently will need bespoke handling in the
gen_nodes_support.pl
On 25.03.22 14:32, Tom Lane wrote:
Peter Eisentraut writes:
On 24.03.22 22:57, David Rowley wrote:
Also, I'm quite keen to see this work make it into v15. Do you think
you'll get time to do that? Thanks for working on it.
My thinking right now is to wait for the PG16 branch to open and
Peter Eisentraut writes:
> On 24.03.22 22:57, David Rowley wrote:
>> Also, I'm quite keen to see this work make it into v15. Do you think
>> you'll get time to do that? Thanks for working on it.
> My thinking right now is to wait for the PG16 branch to open and then
> consider putting it in
On 24.03.22 22:57, David Rowley wrote:
* Unknown attributes are ignored. Some additional attributes are used for
* special "hack" cases.
I think these really should all be documented. If someone needs to
use one of these hacks then they're going to need to trawl through
Perl code to see
On Fri, 18 Feb 2022 at 19:52, Peter Eisentraut
wrote:
> [ v5-0001-Automatically-generate-node-support-functions.patch ]
I've been looking over the patch and wondering the best way to move
this forward.
But first a couple of things I noted down from reading the patch:
1. You're written:
*
On 14.02.22 18:09, Tom Lane wrote:
* It's time for action on the business about extracting comments
from the to-be-deleted code.
done
* The Perl script is kind of under-commented for my taste.
It lacks a copyright notice, too.
done
* In the same vein, I should not have to
Hi,
On 2022-02-14 20:47:33 -0500, Tom Lane wrote:
> I think that most of the intellectual content in this patch is getting
> the data source nailed down, ie putting the annotations into the *nodes.h
> files and building the code to parse that. I don't have a problem
> with throwing away and
Andres Freund writes:
> On 2022-02-14 18:32:21 -0500, Tom Lane wrote:
>> I think that finishing out and committing this patch is a fine step
>> on the way to that.
> I think most of gen_node_support.pl would change - a lot of that is generating
> the node functions, which would not be needed
Hi,
On 2022-02-14 18:32:21 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I do however not think it's a good idea to commit something generating
> > something like the existing node functions vs going for a metadata based
> > approach at dealing with node functions. That aspect of my
Andres Freund writes:
> I do however not think it's a good idea to commit something generating
> something like the existing node functions vs going for a metadata based
> approach at dealing with node functions. That aspect of my patchset is
> independent of the libclang vs script debate.
I
Hi,
On 2022-02-14 12:09:47 -0500, Tom Lane wrote:
> I'm in favor of moving forward with this. I do not like the
> libclang-based approach that Andres was pushing, because of the
> jump in developer tooling requirements that it'd cause.
FWIW, while I don't love the way the header parsing stuff
Peter Eisentraut writes:
> What do people think about this patch now?
I'm in favor of moving forward with this. I do not like the
libclang-based approach that Andres was pushing, because of the
jump in developer tooling requirements that it'd cause.
Eyeballing the patch a bit, I do have some
What do people think about this patch now?
I have received some feedback on several small technical issues, which
have all been fixed. This patch has been around for several commit
fests now and AFAICT, nothing has broken it. This is just to indicate
that the parsing isn't as flimsy as one
Rebased patch to resolve some merge conflicts
On 29.12.21 12:08, Peter Eisentraut wrote:
On 12.10.21 15:52, Andrew Dunstan wrote:
I haven't been through the whole thing, but I did notice this: the
comment stripping code looks rather fragile. I think it would blow up if
there were a
On 12.10.21 15:52, Andrew Dunstan wrote:
I haven't been through the whole thing, but I did notice this: the
comment stripping code looks rather fragile. I think it would blow up if
there were a continuation line not starting with qr/\s*\*/. It's a lot
simpler and more robust to do this if you
On 10/11/21 10:22 AM, Peter Eisentraut wrote:
>
> On 15.09.21 21:01, Peter Eisentraut wrote:
>> On 17.08.21 16:36, Peter Eisentraut wrote:
>>> Here is another set of preparatory patches that clean up various
>>> special cases and similar in the node support.
>>
>> This set of patches has been
On 12.10.21 03:06, Corey Huinker wrote:
build support and made the Perl code more portable, so that the cfbot
doesn't have to be sad.
Was this also the reason for doing the output with print statements
rather than using one of the templating libraries? I'm mostly just
curious, and
>
> build support and made the Perl code more portable, so that the cfbot
> doesn't have to be sad.
>
Was this also the reason for doing the output with print statements rather
than using one of the templating libraries? I'm mostly just curious, and
certainly don't want it to get in the way of
On 15.09.21 21:01, Peter Eisentraut wrote:
On 17.08.21 16:36, Peter Eisentraut wrote:
Here is another set of preparatory patches that clean up various
special cases and similar in the node support.
This set of patches has been committed. I'll close this commit fest
entry and come back with
On 17.08.21 16:36, Peter Eisentraut wrote:
Here is another set of preparatory patches that clean up various special
cases and similar in the node support.
This set of patches has been committed. I'll close this commit fest
entry and come back with the main patch series in the future.
On Tue, Sep 07, 2021 at 10:57:02AM +0200, Peter Eisentraut wrote:
> On 02.09.21 20:53, Jacob Champion wrote:
> >>0004-Make-node-output-prefix-match-node-structure-name.patch
> >>
> >>Some nodes' output/read functions use a label that is slightly different
> >>from their node name, e.g., "NOTIFY"
On 02.09.21 20:53, Jacob Champion wrote:
0004-Make-node-output-prefix-match-node-structure-name.patch
Some nodes' output/read functions use a label that is slightly different
from their node name, e.g., "NOTIFY" instead of "NOTIFYSTMT". This
cleans that up so that an automated approach doesn't
On Tue, 2021-08-17 at 16:36 +0200, Peter Eisentraut wrote:
> Here is another set of preparatory patches that clean up various special
> cases and similar in the node support.
>
> 0001-Remove-T_Expr.patch
>
> Removes unneeded T_Expr.
>
> 0002-Add-COPY_ARRAY_FIELD-and-COMPARE_ARRAY_FIELD.patch
>
Here is another set of preparatory patches that clean up various special
cases and similar in the node support.
0001-Remove-T_Expr.patch
Removes unneeded T_Expr.
0002-Add-COPY_ARRAY_FIELD-and-COMPARE_ARRAY_FIELD.patch
0003-Add-WRITE_INDEX_ARRAY.patch
These add macros to handle a few cases
Peter Eisentraut writes:
>> The first eight patches are to clean up various inconsistencies to make
>> parsing or generation easier.
> Are there any concerns about the patches 0001 through 0008? Otherwise,
> maybe we could get those out of the way.
I looked through those and don't have any
On 07.06.21 22:27, Peter Eisentraut wrote:
I wrote a script to automatically generate the node support functions
(copy, equal, out, and read, as well as the node tags enum) from the
struct definitions.
The first eight patches are to clean up various inconsistencies to make
parsing or
Hi,
On 2021-07-14 17:42:10 -0400, Tom Lane wrote:
> I think the main reason that the previous patch went nowhere was general
> resistance to making developers install something as complicated as
> libclang --- that could be a big lift on non-mainstream platforms.
I'm still not particularly
Andres Freund writes:
> On 2021-06-08 19:45:58 +0200, Peter Eisentraut wrote:
>> On 08.06.21 15:40, David Rowley wrote:
>>> It's almost 2 years ago now, but I'm wondering if you saw what Andres
>>> proposed in [1]?
>> That project was technologically impressive, but it seemed to have
>>
Hi,
On 2021-06-08 19:45:58 +0200, Peter Eisentraut wrote:
> On 08.06.21 15:40, David Rowley wrote:
> > It's almost 2 years ago now, but I'm wondering if you saw what Andres
> > proposed in [1]? The idea was basically to make a metadata array of
> > the node structs so that, instead of having to
On 08.06.21 15:40, David Rowley wrote:
It's almost 2 years ago now, but I'm wondering if you saw what Andres
proposed in [1]? The idea was basically to make a metadata array of
the node structs so that, instead of having to output large amounts of
.c code to do read/write/copy/equals, instead
On Tue, 8 Jun 2021 at 08:28, Peter Eisentraut
wrote:
>
> I wrote a script to automatically generate the node support functions
> (copy, equal, out, and read, as well as the node tags enum) from the
> struct definitions.
Thanks for working on this. I agree that it would be nice to see
I wrote a script to automatically generate the node support functions
(copy, equal, out, and read, as well as the node tags enum) from the
struct definitions.
The first eight patches are to clean up various inconsistencies to make
parsing or generation easier.
The interesting stuff is in
87 matches
Mail list logo
