Yeb Havinga wrote:
The underlying cause is the failure of the code to recognize that if
relation C inherits from both A and B, where A and B both have column
x, that A.x 'is the same as' B.x, where the 'is the same as' relation
is the same that holds for (A.x, C.x) and (B.x, C.x), which the cod
Robert Haas wrote:
On Mon, Aug 2, 2010 at 2:56 PM, Yeb Havinga wrote:
Hence the ATOneLevelRecursion routing is usable in its
current form for all callers during the prep stage, and not only
ATPrepAddColumn.
Well, only if they happen to want the "visit each table only once"
behavior, which mig
On Mon, Aug 2, 2010 at 2:56 PM, Yeb Havinga wrote:
> I do not completely understand what you mean with the destruction of
> reusability of ATOneLevelRecursion, currently only called by ATPrepAddColumn
> - in the patch it is documented in the definition of relVisited that is it
> visit info for eac
Robert Haas wrote:
I don't think that this is much cleaner than the global variable
solution; you haven't really localized that need to know about the new
flag in any meaningful way, the hacks in ATOneLevelRecusion()
basically destroy any pretense of that code possibly being reusable
for some oth
On Mon, Aug 2, 2010 at 10:47 AM, Yeb Havinga wrote:
>>> The attached patch uses the globally defined list.
>>
>> I can't speak for any other committer, but personally I'm prepared to
>> reject out of hand any solution involving a global variable. This
>> code is none to easy to follow as it is an
Robert Haas wrote:
On Mon, Aug 2, 2010 at 9:20 AM, Yeb Havinga wrote:
The attached patch uses the globally defined list.
I can't speak for any other committer, but personally I'm prepared to
reject out of hand any solution involving a global variable. This
code is none to easy to follow as it
On Mon, Aug 2, 2010 at 9:20 AM, Yeb Havinga wrote:
> Robert Haas wrote:
>>
>> I agree that's the crux of the problem, but I can't see solving it
>> with a global variable. I realize you were just testing...
>
> Yes it was just a test. However, somewhere information must be kept or
> altered so it
Robert Haas wrote:
I agree that's the crux of the problem, but I can't see solving it
with a global variable. I realize you were just testing...
Yes it was just a test. However, somewhere information must be kept or
altered so it can be detected that a relation has already been visited,
i.e
On Fri, Jul 30, 2010 at 4:38 PM, Yeb Havinga wrote:
>> I'm looking at ATPrepAddColumn right now, where there is actually some
>> comments about getting the right attinhcount in the case of multiple
>> inherited children, but it's the first time I'm looking at this part of
>> PostgreSQL and it need
On Fri, Jul 30, 2010 at 10:22, Robert Haas wrote:
> OK, it looks like level_2_parent is actually irrelevant to this issue.
> So here's a slightly simplified test case:
>
> DROP SCHEMA IF EXISTS test_inheritance CASCADE;
> CREATE SCHEMA test_inheritance;
> SET search_path TO test_inheritance;
>
>
Yeb Havinga wrote:
Robert Haas wrote:
This still leaves open the question of what to do about the similar
case involving attributes:
That problem looks significantly more difficult to solve, though.
I'm looking at ATPrepAddColumn right now, where there is actually some
comments about gettin
Robert Haas wrote:
It seems to me that it should only recurse to its children
if the constraint was really added, rather than merged into an
existing constraint, because if it was merged into an existing
constraint, then the children already have it.
Yes. (then the children already have it -> alr
On Fri, Jul 30, 2010 at 11:35 AM, Robert Haas wrote:
> In the case of coninhcount, I believe that the fix actually is quite
> simple, although of course it's possible that I'm missing something.
> Currently, ATAddConstraint() first calls AddRelationNewConstraints()
> to add the constraint, or poss
On Fri, Jul 30, 2010 at 11:39 AM, Tom Lane wrote:
> Yeb Havinga writes:
>> Regard the following lattice (direction from top to bottom):
>
>> 1
>> |\
>> 2 3
>> \|\
>> 4 5
>> \|
>> 6
>
>> When adding a constraint to 1, the proper coninhcount for that
>> constraint on relation 6 is 2. But
Yeb Havinga writes:
> Regard the following lattice (direction from top to bottom):
> 1
> |\
> 2 3
> \|\
> 4 5
>\|
> 6
> When adding a constraint to 1, the proper coninhcount for that
> constraint on relation 6 is 2. But the code currently counts to 3, since
> 6 is reached by paths 1
On Fri, Jul 30, 2010 at 10:46 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 30, 2010 at 10:23 AM, Tom Lane wrote:
>>> Uh, full stop there. If you think that the multiply-inherited column
>>> logic is wrong, it's you that is mistaken --- or at least you're going
>>> to have to do a lo
Tom Lane wrote:
Robert Haas writes:
Since the output in the previous email apparently wasn't sufficient
for you to understand what the problem is, here it is in more detail.
...
Adding a column to the toplevel parent of the inheritance hierarchy
and then dropping it again shouldn't leave a left
Robert Haas writes:
> On Fri, Jul 30, 2010 at 10:23 AM, Tom Lane wrote:
>> Uh, full stop there. If you think that the multiply-inherited column
>> logic is wrong, it's you that is mistaken --- or at least you're going
>> to have to do a lot more than just assert that you don't like it.
>> We spe
On Fri, Jul 30, 2010 at 10:23 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 30, 2010 at 10:11 AM, Tom Lane wrote:
>>> The original design idea was that coninhcount/conislocal would act
>>> exactly like attinhcount/attislocal do for multiply-inherited columns.
>>> Where did we fail to
Robert Haas writes:
> On Fri, Jul 30, 2010 at 10:11 AM, Tom Lane wrote:
>> The original design idea was that coninhcount/conislocal would act
>> exactly like attinhcount/attislocal do for multiply-inherited columns.
>> Where did we fail to copy that logic?
> We didn't. That logic is broken, too
On Fri, Jul 30, 2010 at 10:11 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jul 29, 2010 at 6:57 AM, Henk Enting wrote:
>>> We ran into a problem on 9.0beta3 with check constraints using table
>>> inheritance in a multi-level hierarchy with multiple inheritance.
>
>> Thanks for the report
Robert Haas writes:
> On Thu, Jul 29, 2010 at 6:57 AM, Henk Enting wrote:
>> We ran into a problem on 9.0beta3 with check constraints using table
>> inheritance in a multi-level hierarchy with multiple inheritance.
> Thanks for the report. This bug also appears to exist in 8.4; I'm not
> sure y
On Thu, Jul 29, 2010 at 6:57 AM, Henk Enting wrote:
> We ran into a problem on 9.0beta3 with check constraints using table
> inheritance in a multi-level hierarchy with multiple inheritance.
>
> A test script is provided below and a proposed patch is attached to this
> email.
Thanks for the repor
23 matches
Mail list logo
