Per recent discussion, this does not work because other backends can't
reliably see tuples in a temp table and so cannot run the RI checks
correctly. Seems better to disallow this case than go back to accessing
temp tables through shared buffers. Also, disallow FK references to
ON COMMIT DELETE ROWS tables. We already caught this problem for normal
TRUNCATE, but the path used by ON COMMIT didn't check.
SQLSTATE error codes required by SQL99 (invalid format, datetime field
overflow, interval field overflow, invalid time zone displacement value).
Also emit a HINT about DateStyle in cases where it seems appropriate.
Per recent gripes.
now all that is tested is Rod Taylor's recent addition to allow
this syntax:
UPDATE ... SET <col> = DEFAULT;
If anyone else would like to add more UPDATE tests, go ahead --
I just wanted to write a test for the above functionality, and
couldn't see an existing test that it would be appropriate
to add to.
Neil Conway
as well as the hash function (formerly the comparison function was hardwired
as memcmp()). This makes it possible to eliminate the special-purpose
hashtable management code in execGrouping.c in favor of using dynahash to
manage tuple hashtables; which is a win because dynahash knows how to expand
a hashtable when the original size estimate was too small, whereas the
special-purpose code was too stupid to do that. (See recent gripe from
Stephan Szabo about poor performance when hash table size estimate is way
off.) Free side benefit: when using string_hash, the default comparison
function is now strncmp() instead of memcmp(). This should eliminate some
part of the overhead associated with larger NAMEDATALEN values.
be anything yielding an array of the proper kind, not only sub-ARRAY[]
constructs; do subscript checking at runtime not parse time. Also,
adjust array_cat to make array || array comply with the SQL99 spec.
Joe Conway
datatype by array_eq and array_cmp; use this to solve problems with memory
leaks in array indexing support. The parser's equality_oper and ordering_oper
routines also use the cache. Change the operator search algorithms to look
for appropriate btree or hash index opclasses, instead of assuming operators
named '<' or '=' have the right semantics. (ORDER BY ASC/DESC now also look
at opclasses, instead of assuming '<' and '>' are the right things.) Add
several more index opclasses so that there is no regression in functionality
for base datatypes. initdb forced due to catalog additions.
subplan it starts with, as they may be needed at upper join levels.
See comments added to code for the non-obvious reason why. Per bug report
from Robert Creager.
reduces the number of concurrent processes launched during parallel
regression tests, possibly avoiding failures such as exceeding a user's
max number of processes. This essentially completes the reversion
of 1.27->1.28.
might have inherited from the environment that would possibly cause
psql to fail to connect to the temp installation properly. Per trouble
report from Markus Bertheau 7/1/03.
wait for the postmaster to actually exit. Otherwise running repeated
'make check's tends to misbehave, because we try to remove and recreate
the data directory while the old PM is still alive.
heuristic determination of day vs month in date/time input. Add the
ability to specify that input is interpreted as yy-mm-dd order (which
formerly worked, but only for yy greater than 31). DateStyle's input
component now has the preferred spellings DMY, MDY, or YMD; the older
keywords European and US are now aliases for the first two of these.
Per recent discussions on pgsql-general.
>>ISTM that "source" is worth knowing.
>
> Hm, possibly. Any other opinions?
This version has the seven fields I proposed, including "source". Here's
an example that shows why I think it's valuable:
regression=# \x
Expanded display is on.
regression=# select * from pg_settings where name = 'enable_seqscan';
-[ RECORD 1 ]-----------
name | enable_seqscan
setting | on
context | user
vartype | bool
source | default
min_val |
max_val |
regression=# update pg_settings set setting = 'off' where name =
'enable_seqscan';
-[ RECORD 1 ]---
set_config | off
regression=# select * from pg_settings where name = 'enable_seqscan';
-[ RECORD 1 ]-----------
name | enable_seqscan
setting | off
context | user
vartype | bool
source | session
min_val |
max_val |
regression=# alter user postgres set enable_seqscan to 'off';
ALTER USER
(log out and then back in again)
regression=# \x
Expanded display is on.
regression=# select * from pg_settings where name = 'enable_seqscan';
-[ RECORD 1 ]-----------
name | enable_seqscan
setting | off
context | user
vartype | bool
source | user
min_val |
max_val |
In the first case, enable_seqscan is set to its default value. After
setting it to off, it is obvious that the value has been changed for the
session only. In the third case, you can see that the value has been set
specifically for the user.
Joe Conway
that the regression tests for foreign keys didn't seem to test
a deferred constraint that was not satisified by a later
statement and was not made immediate by set constraints,
so here's a simple added test with a single invalid insert and
a commit.
Stephan Szabo
It also works to create a non-polymorphic aggregate from polymorphic
functions, should you want to do that. Regression test added, docs still
lacking. By Joe Conway, with some kibitzing from Tom Lane.
'scalar op ALL (array)', where the operator is applied between the
lefthand scalar and each element of the array. The operator must
yield boolean; the result of the construct is the OR or AND of the
per-element results, respectively.
Original coding by Joe Conway, after an idea of Peter's. Rewritten
by Tom to keep the implementation strictly separate from subqueries.
