Here's a couple more small fixes that I've made to make my runtime
checker happy with the code. More along the lines of those that
I sent in the past, ie, a pointer to an array != the name of
an array. The last patch is that I mailed about yesterday -- I got
two replies of "do it", so it's done. As far as I can tell, however,
the function in question is never called by pg95, so either way
it can't hurt...
From: "Kurt J. Lidl" <lidl@va.pubnix.com>
Previously Postgres95 wouldn't accept 'order by' clauses with fields
referred to as '<table>.<field>', e.g.:
select t1.field1, t2.field2 from table1 t1, table2 t2
order by t2.field2;
This syntax is required by the ODBC SQL spec.
Submitted by: Dan McGuirk <mcguirk@indirect.com>
While a normal SELECT statement can contain a GROUP BY clause, a cursor
declaration cannot. This was not the case in PG-1.0. Was there a good
reason why this was changed? Are cursors being phased out? Is there any way
to get data with just a SELECT (and without a DECLARE CURSOR ...)?
The patch below seems to fix things. If anyone can see a problem with it,
please let me know. Thanks.
Submitted by: David Smith <dasmith@perseus.tufts.edu>
In postgres95/src/backend/nodes/readfuncs, lines 1188 and 1189,
local_node->relname is taken to point to a NameType, while its
defined as a pointer to char. Both the casting to Name and the
call of namestrcpy should, IMHO, be changed appropriately (first
patch).
As far as I could see from the Linux signal header file,
a signal handler is declared as
typedef void (*__sighandler_t)(int);
Few changes to postgres95/src/backend/storage/lmgr/proc.c seem
appropriate to comply with this.
Finally, postgres95/src/bin/pg_version/pg_version.c defines
a function GetDataHome (by default, returning an integer)
and returns NULL in the function, which isn't an integer...
Submitted by: ernst.molitor@uni-bonn.de
