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(i>0) constraint and get out i<0
> then I think this is a question of education.
I potentially disagree. What are we trying to model here? Sys
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
>
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 check
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 dro
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 journ
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 a
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 10
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 le
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
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 cons
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
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 BET
>> 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 sai
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
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
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 o
>>> 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 al
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 sh
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 effec
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
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
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 attemp
22 matches
Mail list logo
