actually a type-coercion problem.  If you have a function defined on
class A, and class B inherits from A, then the function ought to work
on class B as well --- but coerce_type didn't know that.  Now it does.

mark query as having subselects if a subselect was added from a rule
WHERE condition (as opposed to a rule action).  Also, fix adjustment
of varlevelsup so that it actually has some prospect of working when
inserting an expression containing a subselect into a subquery.

 small changes in formatting.c code (better memory usage ...etc.) and
better
to_char's cache (will fastly for more to_char()s in one query).

(It is probably end of to_char() development in 7.0 cycle.)

                                                Karel

after trying to resolve the item as an input-column name.  This allows us
to be compliant with the SQL92 spec for queries that fall within the spec,
while still accepting the same out-of-spec queries as 6.5 did.  You'll only
lose if there is an output column name that is the same as an input
column name, but doesn't refer to the same value.  7.0 will interpret
such a GROUP BY spec differently than 6.5 did.  No way around that, because
6.5 was clearly not spec compliant.

wrong pointer.

CREATE DB/DROP DB.  If you didn't think they were wrong, try what
happens when you compile with -DCLOBBER_FREED_MEMORY --- database
name displayed in error messages is trashed, because transaction
abort freed it.  Also, remove trailing periods in error messages,
per our prevailing style.

the pain of updating apps to 7.0.  Should we also translate some of
the 'datetime_foo' functions that exist in 6.* ?

so that the fmgr lookup only has to happen once per index scan and not
once per tuple.  Seems to save 5% or so of CPU time for an indexscan.

Implement TIME WITH TIME ZONE type (timetz internal type).
Remap length() for character strings to CHAR_LENGTH() for SQL92
 and to remove the ambiguity with geometric length() functions.
Keep length() for character strings for backward compatibility.
Shrink stored views by removing internal column name list from visible rte.
Implement min(), max() for time and timetz data types.
Implement conversion of TIME to INTERVAL.
Implement abs(), mod(), fac() for the int8 data type.
Rename some math functions to generic names:
 round(), sqrt(), cbrt(), pow(), etc.
Rename NUMERIC power() function to pow().
Fix int2 factorial to calculate result in int4.
Enhance the Oracle compatibility function translate() to work with string
 arguments (from Edwin Ramirez).
Modify pg_proc system table to remove OID holes.

of BufferLocks[] entry just once.  Seems to save 10% or so of the
routine's runtime, which'd not be worth worrying about if it weren't
such a hotspot.

Please
> apply the attached patch to
>
> backend/port/qnx4
>
> Andreas Kardos
>

alpha_cc
> template file. Patch attached.
>
> Andreas Kardos
>

(Alpha).
>
> Andreas Kardos

(Alpha).
>

Please
> apply the attached patch.
>
> Andreas Kardos
>
>

checking postmaster.pid. It's not enough to check the existence
of postmaster.pid since DB recovery might be running.

of tuples we are going to retrieve from a sub-SELECT.  Must have been
half asleep when I did this code the first time :-(

psql script would be dropped silently.

(ie, allow rounding to occur at a digit position left of the decimal
point).  Apparently this is how Oracle handles it, and there are
precedents in other programming languages as well.

Since we detect oversize tuples elsewhere, I see no reason not to allow
string constants that are 'too long' --- after all, they might never get
stored in a tuple at all.

YY_READ_BUF_SIZE, which turns out to have nothing to do with buffer size.
It's just a totally arbitrary upper limit on how much data myinput() is
asked for at one time.

set of SQL-standard type names that we accept.

that the inputs to a given operator can be recursively simplified to
constants, it was evaluating the operator using the op's *original*
(unsimplified) arg list, so that any subexpressions had to be evaluated
again.  A constant subexpression at depth N got evaluated N times.
Probably not very important in practical situations, but it made us look
real slow in MySQL's 'crashme' test...

fireRIRonSubselect was invoked twice at each subselect, leading to an
exponential amount of wasted effort.

gone, replaced by plain a_expr.  The few places where we needed to
distinguish NULL from a_expr are now handled by tests inside the actions
rather than by separate productions.  This allows us to accept queries
like 'SELECT 1 + NULL' without requiring parentheses around the NULL.

subplan: do it if subplan has subplans itself, and always do it if the
subplan is an indexscan.  (I originally set it to materialize an indexscan
only if the indexqual is fairly selective, but I dunno what I was
thinking ... an unselective indexscan is still expensive ...)

category STRING.  Also, if UNKNOWNOID is passed in, return UNKNOWN_TYPE
not USER_TYPE.

coercion code.  I'm beginning to wonder why we have separate candidate
selection routines for functions, operators, and aggregates --- shouldn't
this code all be unified?  But meanwhile,
	SELECT 'a' LIKE 'a';
finally works; the code for dealing with unknown input types for operators
was pretty busted.

subPlans to be considered 'simple'.  This fixes reported problem with
'return exists (select 1 from foo);' in plpgsql function.