Re: [COMMITTERS] 'pgsql/src/test/regress/expected rules.out'

Modified Files:
rules.out
Log Message:
change pgsql to postgres

I have some patches which will change rules.sql to avoid using
getpgusername() altogether, since that returns an installation-dependent
result.

Will apply sometime soon, along with some other changes laying a bit of
groundwork for outer joins so you can start on the planner/optimizer
parts :)

Those will be a synch now that I understand the optimizer. In fact, I
think it all will happen in the executor.

-- 
  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, Pennsylvania 19026

Bruce Momjian wrote:

Will apply ... some other changes laying a bit of
groundwork for outer joins so you can start on the planner/optimizer
parts :)

Those will be a synch now that I understand the optimizer. In fact, I
think it all will happen in the executor.

I've modified executor/nodeMergeJoin.c to walk a left/right/both outer
join, but didn't fill in the part which actually creates the result
tuple (which will be the current left- or right-side tuple plus nulls
for filler). I hope this is up your alley :)

So far, I'm not certain what to pass to the planner. The syntax leads me
to pass a select structure from gram.y with a "JoinExpr" structure in
the "fromClause" list. I need to expand that with a combination of
column names and qualifications, but at the time I see the JoinExpr I
don't have access to the top query structure itself. So I may just keep
a modestly transformed JoinExpr to expand later or to pass to the
planner.

btw, the EXCEPT/INTERSECT stuff from Stefan has some ugliness in gram.y
which needs to be fixed (the shift/reduce conflict is not acceptable for
our release version) and some of that code clearly needs to move to
analyze.c or some other module.

- Tom

Modified Files:
rules.out
Log Message:
change pgsql to postgres

I have some patches which will change rules.sql to avoid using
getpgusername() altogether, since that returns an installation-dependent
result.

Will apply sometime soon, along with some other changes laying a bit of
groundwork for outer joins so you can start on the planner/optimizer
parts :)

Highly appreciated!

I know it was my fault and that it would have been my job to
fix it. But since I've installed glibc-2 (libc6) and
gcc-2.8.1, many regressions fail due to floating point and
error message diff's.

Thanks.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

Bruce Momjian wrote:

Will apply ... some other changes laying a bit of
groundwork for outer joins so you can start on the planner/optimizer
parts :)

Those will be a synch now that I understand the optimizer. In fact, I
think it all will happen in the executor.

I've modified executor/nodeMergeJoin.c to walk a left/right/both outer
join, but didn't fill in the part which actually creates the result
tuple (which will be the current left- or right-side tuple plus nulls
for filler). I hope this is up your alley :)

Nested loop and hash have to be done too.

So far, I'm not certain what to pass to the planner. The syntax leads me
to pass a select structure from gram.y with a "JoinExpr" structure in
the "fromClause" list. I need to expand that with a combination of
column names and qualifications, but at the time I see the JoinExpr I
don't have access to the top query structure itself. So I may just keep
a modestly transformed JoinExpr to expand later or to pass to the
planner.

Can we just set a flag in the RangeTblEntry to indicate if it is an
OUTER join?

btw, the EXCEPT/INTERSECT stuff from Stefan has some ugliness in gram.y
which needs to be fixed (the shift/reduce conflict is not acceptable for
our release version) and some of that code clearly needs to move to
analyze.c or some other module.

Yes. I agree. Got Vadim's stuff merged into Stephan's code. I think a
review of the actual patch is the only solution. It is in the patches list.

-- 
  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, Pennsylvania 19026

I know it was my fault and that it would have been my job to
fix it. But since I've installed glibc-2 (libc6) and
gcc-2.8.1, many regressions fail due to floating point and
error message diff's.

Yeah, that seems to be a problem (or at least an annoyance). I've got
egcs-2.91.57 installed, but for running regression tests I go back to
gcc-2.7.2.1 to get the rounding behavior back as it used to be.

- Tom