This patch forces postgres95 to assume any floating-point value is a
float8. It removes the requirement that you cast all floating-point
constants to float8.
We can remove alot of casts in the regression test after we are sure
this works.
If I have missed anything, would someone let me know. I have tested
inserts of floating-point values into float8 fields, and it worked well.
Casting the number to float4 showed the same precision loss as previous
uncast values showed.
Submitted by: Bruce Momjian <maillist@candle.pha.pa.us>
I've enclosed two patches. The first affects Solaris compilability. The
bug stems from netdb.h (where MAXHOSTNAMELEN is defined on a stock
system). If the user has installed the header files from BIND 4.9.x,
there will be no definition of MAXHOSTNAMELEN. The patch will, if all
else fails, try to include <arpa/nameser.h> and set MAXHOSTNAMELEN to
MAXDNAME, which is 256 (just like MAXHOSTNAMELEN on a stock system).
The second patch adds aliases for "ISNULL" to "IS NULL" and likewise for
"NOTNULL" to "IS NOT NULL". I have not removed the postgres specific
ISNULL and NOTNULL. I noticed this on the TODO list, and figured it would
be easy to remove.
The full semantics are:
[ expression IS NULL ]
[ expression IS NOT NULL ]
--Jason
Submitted by: Jason Wright <jason@oozoo.vnet.net>
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>