On R, 2005-07-15 at 00:24 +0300, Hannu Krosing wrote:
There is a good fundamental reason why we dont let people drop columns
from children or to add them to parent ONLY: if we did not, then there
would be no way to query from the hierarchy.
I can't see any such reason for forbidding
Bruce: could you change this TODO item
o Prevent child tables from altering constraints like CHECK that were
inherited from the parent table
to
o Prevent new child tables from inheriting constraints defined on
parents with keyword ONLY:
alter table ONLY t add constraint c
On Fri, 2005-07-15 at 11:10 +0300, Hannu Krosing wrote:
Bruce: could you change this TODO item
o Prevent child tables from altering constraints like CHECK that were
inherited from the parent table
to
o Prevent new child tables from inheriting constraints defined on
parents
On Fri, 15 Jul 2005, Hannu Krosing wrote:
What comes to Toms's May 20 argument that people would be surprised when
they select form a table whith check(i0) constraint and get out i0
then I think this is a question of education.
I potentially disagree. What are we trying to model here? Systems
On K, 2005-07-13 at 11:53 +0100, Simon Riggs wrote:
We aren't able to exclude the parent table from the above query because
no Constraint was defined upon it. Since, in our example, the parent is
empty there will be little effect on the query performance. It would be
a mistake to attempt to
On N, 2005-07-14 at 00:13 +0300, Hannu Krosing wrote:
On K, 2005-07-13 at 11:53 +0100, Simon Riggs wrote:
We aren't able to exclude the parent table from the above query because
no Constraint was defined upon it. Since, in our example, the parent is
empty there will be little effect on
Hannu Krosing [EMAIL PROTECTED] writes:
It is not yet possible to specify that an inheritance parent has no
rows, and, if so, should always be excluded from the query.
I think that a simple CHECK(false) constraint should be enough for
this.
huh, that's clever.
CE checks are not made
On Thu, 2005-07-14 at 00:13 +0300, Hannu Krosing wrote:
On K, 2005-07-13 at 11:53 +0100, Simon Riggs wrote:
We aren't able to exclude the parent table from the above query because
no Constraint was defined upon it. Since, in our example, the parent is
empty there will be little effect on
On Thu, 2005-07-14 at 15:30 -0400, Greg Stark wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
It is not yet possible to specify that an inheritance parent has no
rows, and, if so, should always be excluded from the query.
I think that a simple CHECK(false) constraint should be enough
CE checks will not currently recognise STABLE functions within a query.
So WHERE clauses such as
DateKey CURRENT DATE
will not cause exclusion because CURRENT DATE is a STABLE function.
CE checks are not made when the parent table is involved in a join.
Is this also the case where
On N, 2005-07-14 at 21:29 +0100, Simon Riggs wrote:
On Thu, 2005-07-14 at 00:13 +0300, Hannu Krosing wrote:
On K, 2005-07-13 at 11:53 +0100, Simon Riggs wrote:
We aren't able to exclude the parent table from the above query because
no Constraint was defined upon it. Since, in our
On Fri, 2005-07-15 at 00:24 +0300, Hannu Krosing wrote:
On N, 2005-07-14 at 21:29 +0100, Simon Riggs wrote:
On Thu, 2005-07-14 at 00:13 +0300, Hannu Krosing wrote:
On K, 2005-07-13 at 11:53 +0100, Simon Riggs wrote:
We aren't able to exclude the parent table from the above query
On Fri, 2005-07-15 at 00:24 +0300, Hannu Krosing wrote:
Btw, not just UNION ALL, but also simple UNION, INTERSECT and EXCEPT
could probably be taught to use CE at some stage.
It turns out that to solve this problem you very nearly have to solve
the any table problem. Thats an extra argument in
I assume this is a TODO and just not in your first batch of work? It seems
like a pretty important piece eventually. Are there any fundamental
difficulties with handling joins eventually?
Its a reasonable size piece of work, and could not be reworked in time
for 8.1.
As you've said
Hannu,
My comment was too terse. What I meant was that you can't do dynamic
exclusion based upon the results of a join. i.e. PPUC2
but what about _static_ exlusion based on constraints ?
I mean if there is a left side table with say a single partition having
CHECK(id_order BETWEEN 1
Simon,
SELECT
FROM Fact, Dimension
WHERE Fact.Key = Dimension.Key
AND Dimension.DescriptiveField = 'Blah'
So, what happens with this:
SELECT
FROM Fact, Dimension
WHERE Fact.Key = Dimension.Key
AND Fact.part = 100;
With Fact defined with 3 partitions:
CHECK(Part BETWEEN1 AND 1000)
On R, 2005-07-15 at 00:24 +0300, Hannu Krosing wrote:
but what about _static_ exlusion based on constraints ?
I mean if there is a left side table with say a single partition having
CHECK(id_order BETWEEN 1 AND 1000)
(either originally or left after eliminating other by other
On Thu, 2005-07-14 at 15:16 -0700, Luke Lonergan wrote:
Simon,
SELECT
FROM Fact, Dimension
WHERE Fact.Key = Dimension.Key
AND Dimension.DescriptiveField = 'Blah'
So, what happens with this:
SELECT
FROM Fact, Dimension
WHERE Fact.Key = Dimension.Key
AND Fact.part = 100;
With
On Thu, 2005-07-14 at 15:07 -0700, Luke Lonergan wrote:
Hannu,
My comment was too terse. What I meant was that you can't do dynamic
exclusion based upon the results of a join. i.e. PPUC2
but what about _static_ exlusion based on constraints ?
I mean if there is a left side table
On Fri, 2005-07-15 at 01:20 +0300, Hannu Krosing wrote:
On R, 2005-07-15 at 00:24 +0300, Hannu Krosing wrote:
but what about _static_ exlusion based on constraints ?
I mean if there is a left side table with say a single partition having
CHECK(id_order BETWEEN 1 AND 1000)
Simon,
It's the first time I've thought to compare the constraint predicates on
joined tables based upon the join restriction. That's possible, but
would take some time to work out.
I've argued that such a construct is not common. I'm open to suggestions
about what *is* common...
I also
On Fri, 2005-07-15 at 00:24 +0300, Hannu Krosing wrote:
And thanks for the good work so far!
I think I should add: thanks for the good ideas so far.
Your ideas and challenges have been essential to progress to date, as
has been all the discussions and feedback.
This is the beginning of a
22 matches
Mail list logo
