be an expression not just a simple Var, so long as only one table is
referenced (so that code isn't really any more difficult than before).
This whole thing is still fundamentally bogus, but at least we can accept
a few more cases than before.

Since plpgsql is a backend extension, it doesn't need libpq...

WHERE in a place where it can be part of a nestloop inner indexqual.
As the code stood, it put the same physical sub-Plan node into both
indxqual and indxqualorig of the IndexScan plan node.  That confused
later processing in the optimizer (which expected that tracing the
subPlan list would visit each subplan node exactly once), and would
probably have blown up in the executor if the planner hadn't choked first.
Fix by making the 'fixed' indexqual be a complete deep copy of the
original indexqual, rather than trying to share nodes below the topmost
operator node.  This had further ramifications though, because we were
making the aforesaid list of sub-Plan nodes during SS_process_sublinks
which is run before construction of the 'fixed' indexqual, meaning that
the copy of the sub-Plan didn't show up in that list.  Fix by rearranging
logic so that the sub-Plan list is built by the final set_plan_references
pass, not in SS_process_sublinks.  This may sound like a mess, but it's
actually a good deal cleaner now than it was before, because we are no
longer dependent on the assumption that planning will never make a copy
of a sub-Plan node.

 Should be more robust to overflows.
 Pass through an unmapped function unchanged, rather than rejecting it.
Add a few more functions, but comment out those which can go through as-is.
Can be used with contrib/odbc/ package, though that isn't committed yet.

    here is an updated version of the bit type with a bugfix and all the necessa
ry
SQL functions defined. This should replace what is currently in contrib. I'd
appreciate any comments on what is there.

Kind regards,

Adriaan

pg_internal.init file in-place, which meant that if another backend
started at about the same time, it might read the incomplete file.
init_irels tries to guard against that, but I have now seen a crash
due to reading bad data from a partly-written file.  (This may indicate
a kernel bug on my platform?  Not sure.)  Anyway, clearly the safest
course is to write the new pg_internal.init file under a unique temporary
filename, and rename it into place only after it's all written.

the syntax ... but gram.y doesn't think so.

- I was unable to compile ecpg due to the ":=" instead of "=" in defining
LIBPQDIR and some other variables in Makefile.global.in
- pg_id (and also pg_encoding) executable was not removed during "make
clean" - there was no $(X) appended to the executable name for rm
- I have added result for int2, int4, float8 and geometry regression tests
        - int2, int2 - yet another message for too large numbers ;-)
        - float8 - it is problably a bug in the newlib C library - it has no
error message for numbers with exponent -400
        - geometry - differences in precision of float numbers
- I have added appropriate lines into resultmap file
- I have modified the script regress.sh to use "case" statement when testing
the hostname. For cygwin the script is called with "i686-pc-cygwin" (on my
machine) as a parameter and this was not catched with the "if" statement.
The check was done for PORTNAME (win) and not HOSTNAME (i.86-pc-cygwin*).

The patch for described modifications is included.

All this modifications can be applied to "current" tree too.
The compilation was done on CygwinB20.1 with gcc 2.95, cygipc library 1.05.
The binaries were able to run also on the newest development snapshot
(2000-03-25).

                        Dan

multibyte encodings. These cannot be used as a backend/database encoding
(OK to use as a client encoding).

actually from an alpha-dec-osf machine, but as far as can be told the
two platforms have the same ideas about past DST rules.

Make similar changes to hpux templates.  Might want to do the same for
other foo_cc and foo_gcc pairs, but will desist until I hear from
someone who uses those platforms.

and do not arbitrarily pull in CFLAGS instead.  This caters to platforms
where the C++ compiler does not like all the same switches the C compiler
wants.

In the event of an elog() while the mode was set to immediate write,
there was no way for it to be set back to the normal delayed write.
The mechanism was a waste of space and cycles anyway, since the only user
was varsup.c, which could perfectly well call FlushBuffer directly.
Now it does just that, and the notion of a write mode is gone.

from gcc.  Which wasn't actually a code bug, but I don't like warnings.