table owner in order to vacuum a table. This is mainly to prevent
denial-of-service attacks via repeated vacuums. Allow VACUUM to gather
statistics about system relations, except for pg_statistic itself ---
not clear that it's worth the trouble to make that case work cleanly.
Cope with possible tuple size overflow in pg_statistic tuples; I'm
surprised we never realized that could happen. Hold a couple of locks
a little longer to try to prevent deadlocks between concurrent VACUUMs.
There still seem to be some problems in that last area though :-(
expressions were written without spaces between operators and operands.
Problem was that something like "if new.f1=new.f2 then" would be translated
to "if $1=$2 then", and the Postgres lexer would tokenize that the wrong
way. Fix is to emit spaces around $paramno constructs to ensure they are
seen as separate tokens.
parallel --- and, not incidentally, removing a common reason for needing
manual cleanup by the DB admin after a crash. Remove initial global
delete of pg_statistics rows in VACUUM ANALYZE; this was not only bad
for performance of other backends that had to run without stats for a
while, but it was fundamentally broken because it was done outside any
transaction. Surprising we didn't see more consequences of that.
Detect attempt to run VACUUM inside a transaction block. Check for
query cancel request before starting vacuum of each table. Clean up
vacuum's private portal storage if vacuum is aborted.
By dropping stats rows here, we eliminate the need for VACUUM to do a
wholesale remove of stats rows. Before, pg_statistics was wiped clean
at the start of VACUUM, ensuring poor planning results for any backends
running in parallel until VACUUM got around to rebuilding the stats for
the relations they are accessing.
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
Make all system indexes unique.
Make all cache loads use system indexes.
Rename *rel to *relid in inheritance tables.
Rename cache names to be clearer.
for the case of errors in backend startup, and proc_exit's method for
coping with errors during proc_exit was *completely* busted. Fixed per
discussions on pghackers around 11/6/99.
it wants to release. This leads to a race condition: does the backend
that's trying to flush the buffer do so before the one that's deleting the
relation does so? Usually no problem, I expect, but on occasion this could
lead to hard-to-reproduce complaints from md.c, especially mdblindwrt.
returns a list of RelOptInfos, eliminating the need for static state
in index_info. That static state was a direct cause of coredumps; if
anything decided to elog(ERROR) partway through an index_info search of
pg_index, the next query would try to close a scan pointer that was
pointing at no-longer-valid memory. Another example of the reasons to
avoid static state variables...
of the index it wants to destroy. This ensures that no other backend is
actively scanning or updating that index. Getting exclusive access on
the index alone is NOT sufficient, because the executor is rather
cavalier about getting locks on indexes --- see ExecOpenIndices().
It might be better to grab index locks in the executor, but I'm not
sure the extra lockmanager traffic is really worth it just to make
index_destroy cleaner.
(whoever thought world-writable files were a good default????). Modify
the pg_pwd code so that pg_pwd is created with 600 permissions. Modify
initdb so that permissions on a pre-existing PGDATA directory are not
blindly accepted: if the dir is already there, it does chmod go-rwx
to be sure that the permissions are OK and the dir actually is owned
by postgres.
inval.c thought it could safely use the catcache to look up the OIDs of
system relations. Not good, considering that inval.c could be called
during catcache loading, if a shared-inval message arrives. Rip out the
lookup logic and instead use the known OIDs from pg_class.h.
table defaults or rules: translate them to a function call so that
parse_coerce doesn't reduce them to a date or time constant immediately.
Also, eliminate a lot of redundancy in the expression grammar by
defining a new nonterminal com_expr, which contains all the productions
that can be shared by a_expr and b_expr.
Warn_restart has been set by the backend main loop. This means that
elog(ERROR) or elog(FATAL) in the postmaster or during backend startup
now have well-defined behavior: proc_exit() rather than coredump.
In the case of elog() inside the postmaster, I think that proc_exit()
is probably not enough --- don't we want our child backends to be
forced to quit too? But I don't understand Vadim's recent changes in
this area, so I'll leave it to him to look over and tweak if needed.
subselects can only appear on the righthand side of a binary operator.
That's still true for quantified predicates like x = ANY (SELECT ...),
but a subselect that delivers a single result can now appear anywhere
in an expression. This is implemented by changing EXPR_SUBLINK sublinks
to represent just the (SELECT ...) expression, without any 'left hand
side' or combining operator --- so they're now more like EXISTS_SUBLINK.
To handle the case of '(x, y, z) = (SELECT ...)', I added a new sublink
type MULTIEXPR_SUBLINK, which acts just like EXPR_SUBLINK used to.
But the grammar will only generate one for a multiple-left-hand-side
row expression.
circumstances:
=> select * from foo\x\t\pset border 0 \p\g\\select * from bar;
Also the release prep update so the sql_help.h is generated before
packaging.
Peter.
nulls with non-nulls using proper three-valued boolean logic. Also clean
up ExecQual to make it clearer that ExecQual *does* follow the SQL spec
for boolean nulls. See '[BUGS] (null) != (null)' thread around 10/26/99
for more detail.
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
Now indexes of pg_class and pg_type are unique indexes
and guarantee the uniqueness of correponding attributes.
heap_create() was changed to take another boolean parameter
which allows to postpone the creation of disk file.
The name of rd_nonameunlinked was changed to rd_unlinked.
It is used generally(not only for noname relations) now.
Requires initdb.
Apparently, back in the dim reaches of prehistory, the parser couldn't
be trusted to label Const nodes with the correct constbyval value ...
and someone preferred to patch around this in copyObject rather than
fix the problem at the source. The problem is long gone, but the hack
lingered on. Until now.
in the TupleDesc that the caller already has (for call from ExecMain) or
can make just as easily as ExecInitJunkFilter() can (for call from
ExecAppend). Also, don't bother to build a junk filter for an INSERT
operation that doesn't actually need one, which is the normal case.
In particular, don't bother to look up type information for attributes
where we're not actually going to use it, and avoid copying entire tlist
structure when it's not necessary.
during initial run formation by keeping both current run and next-run
tuples in the same heap (yup, Knuth is smarter than I am). And, during
merge passes, make use of available sort memory to load multiple tuples
from any one input 'tape' at a time, thereby improving locality of
access to the temp file.
before calling execProject, when the outerPlan has returned zero tuples.
I took this out under the mistaken impression that the input tuple
couldn't be referenced by execProject if we weren't in GROUP BY mode.
But it can, if we're in an UPDATE or DELETE...
One, it now returns the previous hook. That way people don't have to dig
around in libpq-int.h for that information anymore. It previously
returned void, so there should be no incompatibilities.
Second, you cannot set the callback to NULL anymore. (Of course you can
still call it with NULL just to get the current hook.) The way libpq uses
the callback pointer, having a NULL there wasn't very healthy.
Peter Eisentraut
The following patch extends the COMMENT ON functionality to the
rest of the database objects beyond just tables, columns, and views. The
grammer of the COMMENT ON statement now looks like:
COMMENT ON [
[ DATABASE | INDEX | RULE | SEQUENCE | TABLE | TYPE | VIEW ] <objname>
|
COLUMN <relation>.<attribute> |
AGGREGATE <aggname> <aggtype> |
FUNCTION <funcname> (arg1, arg2, ...) |
OPERATOR <op> (leftoperand_typ rightoperand_typ) |
TRIGGER <triggername> ON relname>
Mike Mascari
(mascarim@yahoo.com)
eliminating some wildly inconsistent coding in various parts of the
system. I set MAXPGPATH = 1024 in config.h.in. If anyone is really
convinced that there ought to be a configure-time test to set the
value, go right ahead ... but I think it's a waste of time.
when an initdb-forcing change has been applied within a development cycle.
PG_VERSION serves this purpose for official releases, but we can't bump
the PG_VERSION number every time we make a change to the catalogs during
development. Instead, increase the catalog version number to warn other
developers that you've made an incompatible change. See my mail to
pghackers for more info.
fix recently applied to backend's lexer). I see that YY_USES_REJECT
still gets defined for this lexer, which means it's going to have trouble
parsing really long tokens. Not sure if it's worth doing anything about
that or not; I don't have the interest right now to understand why
ecpg's additions to the syntax cause this problem...
This patch fix a TODO list item.
* require SELECT DISTINCT target list to have all ORDER BY columns
example
ogawa=> select distinct x from t1 order by y;
ERROR: ORDER BY columns must appear in SELECT DISTINCT target list
---
Atsushi Ogawa
boundary-condition bug in myinput() which caused flex scanner to fail
on tokens larger than a bufferload. Turns out flex doesn't want null-
terminated input ... and if it gives you a 1-character buffer, you'd
better supply a character, not a null, lest you be thought to be
reporting end of input.
proc_exit time. I discovered that if the frontend closes the connection
when you're inside a transaction block, there is nothing ensuring that
temp files go away ... I wonder whether proc_exit ought to try to do an
explicit transaction abort?
a generalized module 'tuplesort.c' that can sort either HeapTuples or
IndexTuples, and is not tied to execution of a Sort node. Clean up
memory leakages in sorting, and replace nbtsort.c's private implementation
of mergesorting with calls to tuplesort.c.
recycle storage within sort temp file on a block-by-block basis. This
reduces peak disk usage to essentially just the volume of data being
sorted, whereas it had been about 4x the data volume before.
>From the ORACLE 7 SQL Language Reference Manual:
-----------------------------------------------------
COMMENT
Purpose:
To add a comment about a table, view, snapshot, or
column into the data dictionary.
Prerequisites:
The table, view, or snapshot must be in your own
schema
or you must have COMMENT ANY TABLE system privilege.
Syntax:
COMMENT ON [ TABLE table ] |
[ COLUMN table.column] IS 'text'
You can effectively drop a comment from the database
by setting it to the empty string ''.
-----------------------------------------------------
Example:
COMMENT ON TABLE workorders IS
'Maintains base records for workorder information';
COMMENT ON COLUMN workorders.hours IS
'Number of hours the engineer worked on the task';
to drop a comment:
COMMENT ON COLUMN workorders.hours IS '';
The current patch will simply perform the insert into
pg_description, as per the TODO. And, of course, when
the table is dropped, any comments relating to it
or any of its attributes are also dropped. I haven't
looked at the ODBC source yet, but I do know from
an ODBC client standpoint that the standard does
support the notion of table and column comments.
Hopefully the ODBC driver is already fetching these
values from pg_description, but if not, it should be
trivial.
Hope this makes the grade,
Mike Mascari
(mascarim@yahoo.com)
BufFile so that it handles multi-segment temporary files transparently.
This allows sorts and hashes to work with data exceeding 2Gig (or whatever
the local limit on file size is). Change psort.c to use relative seeks
instead of absolute seeks for backwards scanning, so that it won't fail
when the data volume exceeds 2Gig.
I have changed a bit the makefiles for the win32 port - the *.def files
(created when building shared libraries) are now clean from
Makefile.shlib.
I have also removed "-g" from CFLAGS in the "cygwin32" template - it can
be
enabled when running configure.
Dan
database, but they get truncated at the first NUL by lo_read
when they are read back. The reason for this is that lo_read in
Pg.xs is using the default:
OUTPUT:
RETVAL
buf
which uses C's strlen() to work out the length of the scalar.
The code ought to read something more like:
OUTPUT:
RETVAL
buf sv_setpvn((SV*)ST(2), buf, RETVAL);
I am not sure if this needs to be done on both lo_read methods
in this file, but I changed both and have not since had any
problems with truncated BLOBs.
Douglas Thomson <dougt@mugc.cc.monash.edu.au>
Cygwin snapshots (tested on 990115 which is recommended to use - it fixes
some errors in B20.1)
And I have another patch for including <sys/ipc.h> before <sys/sem.h> in
backend/storage/lmgr/proc.c - it is required due the design of cygipc
headers
Dan
