On Thu, Aug 5, 2010 at 9:59 AM, Tom Lane wrote:
> Well, if it were only a hint, and thus didn't actually "prevent"
> anything, then it wouldn't be breaking compatibility. But I don't
> like the idea much either. It would be extremely expensive, if not
> impossible, to determine whether all paren
Robert Haas writes:
> Yeb Havinga writes:
>> The root cause seems to center around multiple inheritance of the same
>> column without a common ancestor. Another way to approach the problem, is to
>> prevent the user to create a setup, i.e. when adding a column to B that
>> already exists in A, or
On Thu, Aug 5, 2010 at 6:15 AM, Yeb Havinga wrote:
> Tom Lane wrote:
>>
>> Yeb Havinga writes:
>>
>>>
>>> A.a_column B.a_column
>>> | /
>>> v v
>>> C.a_column
>>> C inherits from A and B.
>>>
>>
>> Well, if A and B inherited the column from a common ancestor, he can
>>
Tom Lane wrote:
Yeb Havinga writes:
A.a_columnB.a_column
| /
v v
C.a_column
C inherits from A and B.
Well, if A and B inherited the column from a common ancestor, he can
easily do that. If not, maybe he should have thought harder before he
started.
Yeb Havinga writes:
> Tom Lane wrote:
>> I agree, this idea seems completely nuts. It is *not* reasonable for
>> an action applied to a child to change the definition of the parent.
> Also not in the case that we're talking about here?
> A.a_columnB.a_column
> | /
> v v
Tom Lane wrote:
Andrew Dunstan writes:
On 08/04/2010 06:41 AM, Robert Haas wrote:
Uh, really? Wow. You want to follow the inheritance hierarchy in
both directions, both down and up? That seems like it could be
confusing.
It seems more than confusing. It seems fundamentally wrong. It would
Andrew Dunstan writes:
> On 08/04/2010 06:41 AM, Robert Haas wrote:
>> Uh, really? Wow. You want to follow the inheritance hierarchy in
>> both directions, both down and up? That seems like it could be
>> confusing.
> It seems more than confusing. It seems fundamentally wrong. It would
> cert
On 08/04/2010 06:41 AM, Robert Haas wrote:
On Wed, Aug 4, 2010 at 6:41 AM, Yeb Havinga wrote:
If child inherits column A from parent1 and parent2, and it is then
renamed to B in parent2, what should the name be in the child after
the rename is completed?
The column should be renamed to B in
Robert Haas wrote:
On Wed, Aug 4, 2010 at 6:41 AM, Yeb Havinga wrote:
If child inherits column A from parent1 and parent2, and it is then
renamed to B in parent2, what should the name be in the child after
the rename is completed?
The column should be renamed to B in parent2, child a
On Wed, Aug 4, 2010 at 6:41 AM, Yeb Havinga wrote:
>> If child inherits column A from parent1 and parent2, and it is then
>> renamed to B in parent2, what should the name be in the child after
>> the rename is completed?
>
> The column should be renamed to B in parent2, child and parent1.
Uh, rea
Robert Haas wrote:
On Wed, Aug 4, 2010 at 3:48 AM, Yeb Havinga wrote:
I just read that thread. In the beginning there is a short discussion what
the non-astonishing behaviour of the RENAME in the case of multiple origin
inheritance should be, which is preventing renames or any property chang
On Wed, Aug 4, 2010 at 3:48 AM, Yeb Havinga wrote:
> I just read that thread. In the beginning there is a short discussion what
> the non-astonishing behaviour of the RENAME in the case of multiple origin
> inheritance should be, which is preventing renames or any property change in
> that case. I
Robert Haas wrote:
On Tue, Aug 3, 2010 at 3:05 PM, Yeb Havinga wrote:
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 a
On Tue, Aug 3, 2010 at 3:05 PM, Yeb Havinga wrote:
> 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
>
14 matches
Mail list logo
