available (else there's no way to interpret the list links). Change
pg_locks view to show transaction ID locks separately from ordinary
relation locks. Avoid showing N duplicate rows when the same lock is
held multiple times (seems unlikely that users care about exact hold
count). Improve documentation.
The -n and -N options were removed. Quoting is now smart enough to
supply quotes if and only if necessary.
Numerical types are now printed without quotes, except in cases of
special values such as NaN.
Boolean values printed as true and false.
Most string literals now do not escape whitespace characters (newlines,
etc.) for portability.
SET SESSION AUTHORIZATION argument is a string literal, to follow SQL.
Made commands output by pg_dump use consistent spacing and indentation.
This patch is an updated version of the lock listing patch. I've made
the following changes:
- write documentation
- wrap the SRF in a view called 'pg_locks': all user-level
access should be done through this view
- re-diff against latest CVS
One thing I chose not to do is adapt the SRF to use the anonymous
composite type code from Joe Conway. I'll probably do that eventually,
but I'm not really convinced it's a significantly cleaner way to
bootstrap SRF builtins than the method this patch uses (of course, it
has other uses...)
Neil Conway
composite type capability makes it possible to create a system view
based on a table function in a way that is hopefully palatable to
everyone. The attached patch takes advantage of this, moving
show_all_settings() from contrib/tablefunc into the backend (renamed
all_settings(). It is defined as a builtin returning type RECORD. During
initdb a system view is created to expose the same information presently
available through SHOW ALL. For example:
test=# select * from pg_settings where name like '%debug%';
name | setting
-----------------------+---------
debug_assertions | on
debug_pretty_print | off
debug_print_parse | off
debug_print_plan | off
debug_print_query | off
debug_print_rewritten | off
wal_debug | 0
(7 rows)
Additionally during initdb two rules are created which make it possible
to change settings by updating the system view -- a "virtual table" as
Tom put it. Here's an example:
Joe Conway
pg_language.lancompiler
pg_operator.oprprec
pg_operator.oprisleft
pg_proc.proimplicit
pg_proc.probyte_pct
pg_proc.properbyte_cpu
pg_proc.propercall_cpu
pg_proc.prooutin_ratio
pg_shadow.usetrace
pg_type.typprtlen
pg_type.typreceive
pg_type.typsend
Attempts to use the obsoleted attributes of pg_operator or pg_proc
in the CREATE commands will be greeted by a warning. For pg_type,
there is no warning (yet) because pg_dump scripts still contain these
attributes.
Also remove new but already obsolete spellings
isVolatile, isStable, isImmutable in WITH clause. (Use new syntax
instead.)
handled as special productions. This is needed to keep us honest about
user-schema type names that happen to coincide with system type names.
Per pghackers discussion 24-Apr. To avoid bloating the keyword list
too much, I removed the translations for datetime, timespan, and lztext,
all of which were slated for destruction several versions back anyway.
DROP RULE and COMMENT ON RULE syntax adds an 'ON tablename' clause,
similar to TRIGGER syntaxes. To allow loading of existing pg_dump
files containing COMMENT ON RULE, the COMMENT code will still accept
the old syntax --- but only if the target rulename is unique across
the whole database.
entries, per pghackers discussion. This fixes aggregates to live in
namespaces, and also simplifies/speeds up lookup in parse_func.c.
Also, add a 'proimplicit' flag to pg_proc that controls whether a type
coercion function may be invoked implicitly, or only explicitly. The
current settings of these flags are more permissive than I would like,
but we will need to debate and refine the behavior; for now, I avoided
breaking regression tests as much as I could.
the parsetree representation. As yet we don't *do* anything with schema
names, just drop 'em on the floor; but you can enter schema-compatible
command syntax, and there's even a primitive CREATE SCHEMA command.
No doc updates yet, except to note that you can now extract a field
from a function-returning-row's result with (foo(...)).fieldname.
has an alias SERIAL4 and a sister SERIAL8. SERIAL8 is just the same
except the created column is type int8 not int4.
initdb forced. Note this also breaks any chance of pg_upgrade from 7.1,
unless we hack up pg_upgrade to drop and recreate sequences. (Which is
not out of the question, but I don't wanna do it.)
for speed reasons; its result type also changes to int8. avg() on these
datatypes now accumulates the running sum in int8 for speed; but we still
deliver the final result as numeric, so that fractional accuracy is
preserved.
count() now counts and returns in int8, not int4. I am a little nervous
about this possibly breaking users' code, but there didn't seem to be
a strong sentiment for avoiding the problem. If we get complaints during
beta, we can change count back to int4 and add a "count8" aggregate.
For that matter, users can do it for themselves with a simple CREATE
AGGREGATE command; the int4inc function is still present, so no C hacking
is needed.
Also added max() and min() aggregates for OID that do proper unsigned
comparison, instead of piggybacking on int4 aggregates.
initdb forced.
default, but OIDS are removed from many system catalogs that don't need them.
Some interesting side effects: TOAST pointers are 20 bytes not 32 now;
pg_description has a three-column key instead of one.
Bugs fixed in passing: BINARY cursors work again; pg_class.relhaspkey
has some usefulness; pg_dump dumps comments on indexes, rules, and
triggers in a valid order.
initdb forced.
in cases of qualified rules as well as unqualified ones. Tweak rules
test to avoid cluttering output with dummy SELECT results. Update
documentation to match code.
pg_stats to provide controlled (and, hopefully, more readable) access
to statistics. Comments on definition of pg_stats welcome.
I didn't force initdb, but the rules regress test will fail until you
do one.
new separate relkind for views (per some discussion back in September).
I didn't force initdb, but rules regress test will show differences
until you do one.
after that dynamic loading isn't working and shared memory handling is
broken.
Attached with this message, there is a Zip file which contain :
* beos.diff = patch file generated with difforig
* beos = folder with beos support files which need to be moved in /
src/backend/port
* expected = foler with three file for message and precision
difference in regression test
* regression.diff = rule problem (need to kill the backend manualy)
* dynloader = dynloader files (they are also in the pacth files,
but there is so much modification that I have join full files)
Everything works except a problem in 'rules' Is there some problems
with rules in the current tree ? It used to works with last week tree.
Cyril VELTER
There is still no effective difference but it will kick in once setuid
functions exist (not included here). Make old getpgusername() alias for
current_user.
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.
which is broken in some weird way that I don't understand. I think it
may be exposing a bug in the new psql --- for one thing, I get different
results when I run psql by hand than the regress script gets. What
the heck???
mentioned in FROM but not elsewhere in the query: such tables should be
joined over anyway. Aside from being more standards-compliant, this allows
removal of some very ugly hacks for COUNT(*) processing. Also, allow
HAVING clause without aggregate functions, since SQL does. Clean up
CREATE RULE statement-list syntax the same way Bruce just fixed the
main stmtmulti production.
CAUTION: addition of a field to RangeTblEntry nodes breaks stored rules;
you will have to initdb if you have any rules.
they have no hardwired limit on the length of a rule's text. Fix a couple
of minor bugs in passing --- deparsed UPDATE queries didn't have quotes
around relation name, and quotes and backslashes in constant values weren't
backslash-quoted.
in rules regression test, in order to eliminate bogus test 'failures'
that occur due to platform-dependent and join-implementation-dependent
ordering of tuples. I'm not sure that I got all of the SELECTs that need
ordering clauses --- we may need some more. But this takes care of the
diffs between my platform and Jan's.
rule system semantics by having Var nodes referenced across multiple
parsetrees when rules split them.
Added more tests to the rules regression test.
The code in question resulted from v6.3 based development and was
a little careless applied to the v6.5 source tree.
Jan
for against a just updated CVS tree. It contains
Partial new rewrite system that handles subselects, view
aggregate columns, insert into select from view, updates
with set col = view-value and select rules restriction to
view definition.
Updates for rule/view backparsing utility functions to
handle subselects correct.
New system views pg_tables and pg_indexes (where you can
see the complete index definition in the latter one).
Enabling array references on query parameters.
Bugfix for functional index.
Little changes to system views pg_rules and pg_views.
The rule system isn't a release-stopper any longer.
But another stopper is that I don't know if the latest
changes to PL/pgSQL (not already in CVS) made it compile on
AIX. Still wait for some response from Dave.
Jan