- Made some chars const as proposed by Stefan Huehner <stefan@huehner.org>.
- Synced parser and keyword lists.
- Copied two token parsing from backend parser to ecpg parser.
- Also added a test case for this.
skeleton scripts calling them. To make it easier for the buildfarm
(or other "outside callers") to use these modules directly.
Per suggestion from Andrew Dunstan.
executed in read_only mode. This could lead to various relatively-subtle
failures, such as an allegedly stable function returning non-stable results.
Bug goes all the way back to the introduction of read-only mode in 8.0.
Per report from Gaetano Mendola.
available information about the typmod of an expression; namely, Const,
ArrayRef, ArrayExpr, and EXPR and ARRAY SubLinks. In the ArrayExpr and
SubLink cases it wasn't really the data structure's fault, but exprTypmod()
being lazy. This seems like a good idea in view of the expected increase in
typmod usage from Teodor's work to allow user-defined types to have typmods.
In particular this responds to the concerns we had about eliminating the
special-purpose hack that exprTypmod() used to have for BPCHAR Consts.
We can now tell whether or not such a Const has been cast to a specific
length, and report or display properly if so.
initdb forced due to changes in stored rules.
was expecting there to be no regular table named 'foo', but it turns out
the rules test transiently creates one, so that plancache would sometimes
fail. I couldn't reproduce that in quite a few tries here, but several
buildfarm machines have shown the failure. Fix by renaming plancache's
temp table to something nonconflicting.
uses SPI plans, this finally fixes the ancient gotcha that you can't
drop and recreate a temp table used by a plpgsql function.
Along the way, clean up SPI's API a little bit by declaring SPI plan
pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but
helps to forestall simple programming mistakes. (I have changed some
but not all of the callers to match; there are still some "void *"'s
in contrib and the PL's. This is intentional so that we can see if
anyone's compiler complains about it.)
did not expect that a DEAD tuple could follow a RECENTLY_DEAD tuple in an
update chain, but because the OldestXmin rule for determining deadness is a
simplification of reality, it is possible for this situation to occur
(implying that the RECENTLY_DEAD tuple is in fact dead to all observers,
but this patch does not attempt to exploit that). The code would follow a
chain forward all the way, but then stop before a DEAD tuple when backing
up, meaning that not all of the chain got moved. This could lead to copying
the chain multiple times (resulting in duplicate copies of the live tuple at
its end), or leaving dangling index entries behind (which, aside from
generating warnings from later vacuums, creates a risk of wrong query
results or bogus duplicate-key errors once the heap slot the index entry
points to is repopulated).
The fix is to recheck HeapTupleSatisfiesVacuum while following a chain
forward, and to stop if a DEAD tuple is reached. Each contiguous group
of RECENTLY_DEAD tuples will therefore be copied as a separate chain.
The patch also adds a couple of extra sanity checks to verify correct
behavior.
Per report and test case from Pavan Deolasee.
POSIX-style timezone specs that don't exactly match any database entry will
be treated as having correct USA DST rules. Also, document that this can
be changed if you want to use some other DST rules with a POSIX zone spec.
We could consider changing localtime.c's TZDEFRULESTRING, but since that
facility can only deal with one DST transition rule, it seems fairly useless
now; might as well just plan to override it using a "posixrules" entry.
Backpatch as far as 8.0. There isn't much we can do in 7.x ... either your
libc gets it right, or it doesn't.
with minor editorization by me.
Hstore improvements
* add operation hstore ? text - excat equivalent of exist()
* remove undocumented behaviour of contains operation with NULL value
* now 'key'::text=>NULL returns '"key"=>NULL' instead of NULL
* Add GIN support for contains and exist operations
* Add GiST support for exist operatiion
* improve regression tests
for input/ and output/ directories, because with the addition of
largeobject_1.source, they're not the same list. Apparently the current
buildfarm process does not exercise whether 'make distclean' leaves a
clean tree behind, else the farm would have been failing for awhile.
now complete). Update for the MSVC6/Borland support now being only libpq.
Move most of the information about full MSVC build from README file into
documentation.
module and teach PREPARE and protocol-level prepared statements to use it.
In service of this, rearrange utility-statement processing so that parse
analysis does not assume table schemas can't change before execution for
utility statements (necessary because we don't attempt to re-acquire locks
for utility statements when reusing a stored plan). This requires some
refactoring of the ProcessUtility API, but it ends up cleaner anyway,
for instance we can get rid of the QueryContext global.
Still to do: fix up SPI and related code to use the plan cache; I'm tempted to
try to make SQL functions use it too. Also, there are at least some aspects
of system state that we want to ensure remain the same during a replan as in
the original processing; search_path certainly ought to behave that way for
instance, and perhaps there are others.
even if none of the fields in the pg_class row change. This behavior is
necessary to ensure other backends flush rd_targblock values that might
point to truncated-away pages. We got this right pre-8.2 but it was broken
by overoptimistic change to not write out the pg_class row if unchanged.
Per report from Pavan Deolasee.
fix it. Add macroses DatumGetNDBOX, PG_GETARG_NDBOX and PG_RETURN_NDBOX.
Backpatch for 8.2 too.
Previous versions use version 0 calling conventions. And fmgr code detoast
values for user-defined functions.
check_sql_fn_retval allows binary-compatibility cases, the expression
extracted from an inline-able SQL function might have a type that is only
binary-compatible with the declared function result type. To avoid possibly
changing the semantics of the expression, we should insert a RelabelType node
in such cases. This has only been shown to have bad consequences in recent
8.1 and up releases, but I suspect there may be failure cases in the older
branches too, so patch it all the way back. Per bug #3116 from Greg Mullane.
Along the way, fix an omission in eval_const_expressions_mutator: it failed
to copy the relabelformat field when processing a RelabelType. No known
observable failures from this, but it definitely isn't intended behavior.
Bruce Momjian