I have attached a patch to allow GROUP BY and/or ORDER BY function or
expressions. Note worthy items:
1. The expression or function need not be in the target list.
Example:
SELECT name FROM foo GROUP BY lower(name);
2. Simplified the grammar to use expressions only.
3. Cleaned up earlier patch in this area to make use of existing
utility functions.
3. Reduced some of the members in the SortGroupBy parse node. The
original data members were redundant with the new expression node.
(MUST do a "make clean" now)
4. Added a new parse node "JoinUsing". The JOIN USING clause was
overloading this SortGroupBy structure. With the afore mentioned
reduction of members, the two clauses lost all their commonality.
5. A bug still exist where, if a function or expression is GROUPed BY,
and an aggregate function does not include a attribute from the
expression or function, the backend crashes. (or something like
that) The bug pre-dates this patch. Example:
SELECT lower(a) AS lowcase, count(b) FROM foo GROUP BY lowcase;
*** BOOM ***
--Also when not in target list
SELECT count(b) FROM foo GROUP BY lower(a);
*** BOOM AGAIN ***
Change ordering of IS_BUILTIN_TYPE() macro to optimize lookup.
Make CASH type _not_ equivalent to INT4.
CASH is passed by reference rather than passed by value.
varchar length.
Cleans up code so attlen is always length.
Removed varchar() hack added earlier.
Will fix bug in selecting varchar() fields, and varchar() can be
variable length.
Pass List* of Aggregs into executor, and create needed array there.
No longer need to double-processs Aggregs with second copy in Query.
Fix crash when doing:
select sum(x+1) from test where 1 > 0;
as ints and longs. Touches on quite a few function args as
well. Most other files look ok as far as Oids go...still checking
though...
Since Oids are type'd as unsigned ints, they should prolly be used
with the %ud format string in elog and sprintf messages. Not sure
what kind of strangeness that could produce.
Darren King
I'm able to get through a 'make' of the backend with no errors except
the occasional 'might not be initialized error', which is nothing major,
just annoying.
Have a few patches from D'Arcy to incorporate, but am waiting until I can
get a clean compile first, which I'm hoping to have before bed, or sometime
tomorrow.
cache. I found if I manually added a line to flush the whole relation
cache, the assert error disappeared. Looking through the code, I found
that the relation cache is flushed at the end of each query if the
reference count is zero for the relation. However, printf's showed that
the rd_relcnt(reference count) for the accessed query was not returning
to zero after each query.
It turns out the parser was doing a heap_ropen in parser/analyze.c to
get information about the table's columns, but was not doing a
heap_close.
This was causing the query after the ALTER TABLE ADD to see the old
table structure, and the executor's assert was reporting the problem.
Bruce Momjian
Thomas G. Lockhart
Marc G. Fournier
Vadim B. Mikheev
Bryan Henderson