On Thu, Oct 22, 2015 at 05:14:29PM -0400, Robert Haas wrote:
> On Thu, Oct 22, 2015 at 5:09 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> Despite everybody's best efforts, we mess this up more than is really
> >> desirable. Commit b8fe12a83622b350dc6849f8bb933bd8a86c1424 fixed bugs
> >> in a w
On Friday 23 October 2015 12:41:50 you wrote:
> Requirement of python with pycparser as build dependency is a
> serious cataclysm. For instance, how many buildfarms will survive it?
> This is why Tom and Robert are looking for ways to evade it.
I agree. But it is also a fact that Perl less suited
On Fri, Oct 23, 2015 at 12:31 PM, YUriy Zhuravlev <
u.zhurav...@postgrespro.ru> wrote:
> On Thursday 22 October 2015 09:26:46 David Fetter wrote:
> > On Thu, Oct 22, 2015 at 07:15:35PM +0300, YUriy Zhuravlev wrote:
> > > Hello.
> > > Currently using nodeToString and stringToNode you can not pass a
On Thursday 22 October 2015 09:26:46 David Fetter wrote:
> On Thu, Oct 22, 2015 at 07:15:35PM +0300, YUriy Zhuravlev wrote:
> > Hello.
> > Currently using nodeToString and stringToNode you can not pass a
> > full plan. In this regard, what is the plan to fix it? Or in the
> > under task parallel qu
> I thought that's what you were proposing. Process the struct
> definitions and emit .c files.
We have 2 ways. The first is always to generate the * .c files from the * .h
files. Another way is to generate once from * .h file a XML/JSON and after
generate from it to * .c files (parsing xml/json
On Thu, Oct 22, 2015 at 5:09 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Oct 22, 2015 at 4:32 PM, Tom Lane wrote:
>>> I'm not sure that you could get to a point where you were
>>> generating this stuff from anything that wasn't in essence an arcane
>>> representation of the .c files. I
Robert Haas writes:
> On Thu, Oct 22, 2015 at 4:32 PM, Tom Lane wrote:
>> I'm not sure that you could get to a point where you were
>> generating this stuff from anything that wasn't in essence an arcane
>> representation of the .c files. It might be slightly harder to make
>> errors of omission
On Thu, Oct 22, 2015 at 4:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Oct 22, 2015 at 1:40 PM, YUriy Zhuravlev
>> wrote:
>>> I can gen xml/json from actual struct. I offered XML/JSON as the analysis
>>> of C
>>> code much more difficult. But my current generator just use the structu
Robert Haas writes:
> On Thu, Oct 22, 2015 at 1:40 PM, YUriy Zhuravlev
> wrote:
>> I can gen xml/json from actual struct. I offered XML/JSON as the analysis of
>> C
>> code much more difficult. But my current generator just use the structure
>> from
>> the header files (by pycparser).
> Anythi
On Thu, Oct 22, 2015 at 1:40 PM, YUriy Zhuravlev
wrote:
> On Thursday 22 October 2015 13:25:52 you wrote:
>> It would be more useful, if we're going to autogenerate code,
> Are we going to use autogenerate code?
I thought that's what you were proposing. Process the struct
definitions and emit .c
On Thursday 22 October 2015 13:25:52 you wrote:
> It would be more useful, if we're going to autogenerate code,
Are we going to use autogenerate code?
> to do it from the actual struct definitions.
I can gen xml/json from actual struct. I offered XML/JSON as the analysis of C
code much more diffi
On Thu, Oct 22, 2015 at 1:19 PM, YUriy Zhuravlev
wrote:
> And then another question:
> What do you think if the generated equalfuncs.c, copyfuncs.c, readfuncs.c,
> outfuncs.c from XML or JSON?
> In order not to change the code in four places when changing nodes.
It would be more useful, if we're
On Thursday 22 October 2015 12:53:49 you wrote:
> On Thu, Oct 22, 2015 at 12:15 PM, YUriy Zhuravlev
>
> wrote:
> > Hello.
> > Currently using nodeToString and stringToNode you can not pass a full
> > plan. In this regard, what is the plan to fix it? Or in the under task
> > parallel query does no
On Thu, Oct 22, 2015 at 12:15 PM, YUriy Zhuravlev
wrote:
> Hello.
> Currently using nodeToString and stringToNode you can not pass a full plan. In
> this regard, what is the plan to fix it? Or in the under task parallel query
> does not have such a problem?
It's already fixed. See commits
a0d9f6
On Thu, Oct 22, 2015 at 07:15:35PM +0300, YUriy Zhuravlev wrote:
> Hello.
> Currently using nodeToString and stringToNode you can not pass a
> full plan. In this regard, what is the plan to fix it? Or in the
> under task parallel query does not have such a problem?
>
> > This turns out not to be s
Hello.
Currently using nodeToString and stringToNode you can not pass a full plan. In
this regard, what is the plan to fix it? Or in the under task parallel query
does not have such a problem?
> This turns out not to be straightforward to code, because we
> don't have a generic plan tree walker,
Robert Haas writes:
> On Thu, Sep 24, 2015 at 12:35 PM, Tom Lane wrote:
>> For the record: that's true for the patch you just committed. But once
>> I remove the hopefully-now-dead planner support for recomputing opfuncid,
>> it would get a lot more painful to reverse the decision.
> True. I t
On Thu, Sep 24, 2015 at 12:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> Also, it's not like this change couldn't be UN-done at a future point.
>> I mean, Tom didn't like the flag I added aesthetically, but if we
>> needed it, we could have it. Or we could engineer something else.
>
> For the
Robert Haas writes:
> Also, it's not like this change couldn't be UN-done at a future point.
> I mean, Tom didn't like the flag I added aesthetically, but if we
> needed it, we could have it. Or we could engineer something else.
For the record: that's true for the patch you just committed. But
Alvaro Herrera writes:
> I think allowing an operator's implementation function to change would
> be rather problematic, would it not? There's no way to know whether the
> semantic changes to stored rules would make sense, not least because the
> person running ALTER OPERATOR wouldn't know (== ha
Tom Lane wrote:
> To my mind though, the lack of an ALTER OPERATOR SET FUNCTION command
> is on par with our very limited ability to alter the contents of
> an operator class. In principle it would be nice, but the practical
> value is so small that it's not surprising it hasn't been done ---
> a
On Thu, Sep 24, 2015 at 11:54 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2015-09-23 17:29:50 -0400, Robert Haas wrote:
>>> Well, I can't vouch for what any human being on earth has thought
>>> about over a twenty-year period. It's not intrinsically unreasonable
>>> in my mind to want to a
Andres Freund writes:
> On 2015-09-23 17:29:50 -0400, Robert Haas wrote:
>> Well, I can't vouch for what any human being on earth has thought
>> about over a twenty-year period. It's not intrinsically unreasonable
>> in my mind to want to alter an operator to point at a different
>> procedure.
>
On Wed, Sep 23, 2015 at 7:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 23, 2015 at 5:39 PM, Tom Lane wrote:
>>> Yeah, though I think of that as a longer-term issue, ie we could clean it
>>> up sometime later.
>
>> So, you're thinking of something as simple as the attached?
>
> Rig
On 2015-09-23 17:29:50 -0400, Robert Haas wrote:
> Well, I can't vouch for what any human being on earth has thought
> about over a twenty-year period. It's not intrinsically unreasonable
> in my mind to want to alter an operator to point at a different
> procedure.
Wouldn't we use plan invalidat
Robert Haas writes:
> On Wed, Sep 23, 2015 at 5:39 PM, Tom Lane wrote:
>> Yeah, though I think of that as a longer-term issue, ie we could clean it
>> up sometime later.
> So, you're thinking of something as simple as the attached?
Right. I'll make a mental to-do to see about getting rid of se
On Wed, Sep 23, 2015 at 5:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> But if we're sure we don't want to support that, changing the behavior
>> of the read routines would be fine with me, too. It would even save a
>> few cycles. Would you also want to rip out the stuff that fixes up
>> opfu
Robert Haas writes:
> But if we're sure we don't want to support that, changing the behavior
> of the read routines would be fine with me, too. It would even save a
> few cycles. Would you also want to rip out the stuff that fixes up
> opfuncid as dead code? I assume yes, but sometimes I assume
On Wed, Sep 23, 2015 at 4:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> readfuncs.c deliberately ignores any opfuncid read in for an OpExpr,
>> DistinctExpr, NullIfExpr, or ScalarArrayOpExpr, instead resetting the
>> value in the newly-created node to InvalidOid. This is because it
>> assumes
Robert Haas writes:
> readfuncs.c deliberately ignores any opfuncid read in for an OpExpr,
> DistinctExpr, NullIfExpr, or ScalarArrayOpExpr, instead resetting the
> value in the newly-created node to InvalidOid. This is because it
> assumes we're reading the node from a pg_node_tree column in som
readfuncs.c deliberately ignores any opfuncid read in for an OpExpr,
DistinctExpr, NullIfExpr, or ScalarArrayOpExpr, instead resetting the
value in the newly-created node to InvalidOid. This is because it
assumes we're reading the node from a pg_node_tree column in some
system catalog, and if in t
31 matches
Mail list logo
