Thread: RI status report #1
> Most of the activities after "Second" next step can be > done parallel. I'll commit my changes after that, because > then I'm able to run a full test of deferred constraints > to be sure I'm really on the right track. All co- > developers can join then using the CURRENT tree. > > Any comments? Great. How's that for a comment? :-) -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
wieck@debis.com (Jan Wieck) writes:
> just to give anyone a chance to complain, I'd like to
> describe what I plan to implement for v6.6 in the referential
> integrity (RI) corner.
Jan, I have no comments about the RI features, but I am a little worried
about not creating big headaches in merging different changes. Can we
work out a schedule that will minimize tromping on each others' toes?
I am in the middle of some fairly extensive revisions in
rewriteManip.c, rewriteHandler.c, and ruleutils.c --- basically,
fixing all the routines that recurse through expression trees to use
expression_tree_walker and expression_tree_mutator, for a big space
savings and elimination of a bunch of routine-X-doesn't-handle-node-
type-Y bugs. Also I'm going to fix the rule deparser to use a
stringinfo buffer so it doesn't have any hardwired limits on the textual
length of a rule. And I think I know how to fix some of the problems
with aggregates in subselects, like this one:
create table t1 (name text, value float8);
CREATE
select name from t1 where name IN
(select name from t1 group by name having 2 = count(*));
ERROR: SELECT/HAVING requires aggregates to be valid
(It looks to me like some of the routines recurse into subselects when
they shouldn't. It's a lot easier to see that sort of issue when
there's no code left except the actual Var manipulation and the
nonstandard recursion decisions ;-).)
I intended to finish these up in the next few days and commit them,
but if you've already started major hacking in these files then maybe
we should find another way.
Also, I believe Thomas is in the middle of wide-ranging revisions in
the parser, so you'd better coordinate with him on touching that area.
regards, tom lane
> > Also, I believe Thomas is in the middle of wide-ranging revisions in
> > the parser, so you'd better coordinate with him on touching that area.
> Ah - that's more critical. I just began to add the SET
> CONSTRAINTS command and am through with thinking about the
> CREATE CONSTRAINT TRIGGER too. We all know that our parser is
> a very delicate peace of software. Thomas, could you please
> comment on this?
At the moment I am working on join *syntax*, so my changes are
isolated to gram.y, analyze.c, parse_clause.c, and parse_target.c.
Don't wait for me; I'll bet that we don't collide much, and if we do I
don't mind doing the merge.
Sometime later, once I understand the syntax and have it coded for
inner joins, I'll want to start modifying the parser and planner to
handle outer joins. At that point, I'll be asking for help and advice,
and look forward to your input. But I'm not there yet.
I'm hoping to have some updates committed in a week or so, but things
have been going very slowly with little time to work on this :(
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
On Mon, 27 Sep 1999, Bruce Momjian wrote:
> > Most of the activities after "Second" next step can be
> > done parallel. I'll commit my changes after that, because
> > then I'm able to run a full test of deferred constraints
> > to be sure I'm really on the right track. All co-
> > developers can join then using the CURRENT tree.
> >
> > Any comments?
>
> Great. How's that for a comment? :-)
Damn, I was gonna say that but figured it wasn't enough...:)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
wieck@debis.com (Jan Wieck) writes:
> Tom Lane wrote:
>> I am in the middle of some fairly extensive revisions in
>> rewriteManip.c, rewriteHandler.c, and ruleutils.c --- ...
>> I intended to finish these up in the next few days and commit them,
>> but if you've already started major hacking in these files then maybe
>> we should find another way.
> Do it - I'll wait for you (would you please give me a sign
> then). But I'm 97.5% sure our work has no collision areas.
OK, I'm done with rewriter/ruleutils cleanups, at least for now.
regards, tom lane