seems that my last post didn't make it through. That's good
since the diff itself didn't covered the renaming of
pg_user.h to pg_shadow.h and it's new content.
Here it's again. The complete regression test passwd with
only some float diffs. createuser and destroyuser work.
pg_shadow cannot be read by ordinary user.
The diff looks so simple and easy. But to find it wasn't fun.
It must have been there for a long time. What happened:
When a tuple in one of some central catalogs was updated, the
referenced relation got flushed, so it would be reopened on
the next access (to reflect new triggers, rules and table
structure changes into the relation cache).
Some data (the tupleDescriptor e.g.) is used in the system
cache too. So when a relation is subject to the system cache,
this must know too that a cached system relation got flushed
because the tupleDesc data gets freed during the flush!
For the GRANT/REVOKE on pg_class it was slightly different.
There is some local data in inval.c that gets initialized on
the first invalidation of a tuple in some central catalogs.
This needs a SysCache lookup in pg_class. But when the first
of all commands is a GRANT on pg_class, exactly the needed
tuple is the one actually invalidated. So I added little code
snippets that the initialization of the local variables in
inval.c will already happen during InitPostgres().
Attached is the patch to fix the warning messages from my code. I also
fixed one which wasn't my code. Apart from the usual warnings about the
bison/yacc generated code I only have one other warning message. This
is in gramm.y around line 2234. I wasn't sure of the fix.
I've also replaced all the calls to free() in gramm.y to calls to
pfree(). Without these I was getting backend crashes with GRANT. This
might already have been fixed.
Patch by: wieck@sapserv.debis.de (Jan Wieck)
One of the design rules of PostgreSQL is extensibility. And
to follow this rule means (at least for me) that there should
not only be a builtin PL. Instead I would prefer a defined
interface for PL implemetations.
Makefile.global.
End result, if all goes well, should allow for much easier porting, since
there will no longer be a concept of a "port". Most, if not everything,
*should* be determined by configure, or by the compiler itself. Still
work to be done though :)
/*
* RelationFlushRelation () below will flush relation information
* from the cache. We must call smgrclose to flush relation
* information from SMGR & FMGR, too. We assume that for temp
* relations smgrunlink is already called by heap_destroyr
* and we skip smgrclose for them. - vadim 05/22/97
*/
smgrclose(reln->rd_rel->relsmgr, reln);
- it avoids memory leaks in SMGR & VFD.
RelationFlushRelation():
there is no more call FileInvalidate(RelationGetSystemPort(relation));
- invalid (FileInvalidate() expects File, not SMGR' fd)
- unuseful anyway.
Changes:
* Unique index capability works using the syntax 'create unique
index'.
* Duplicate OID's in the system tables are removed. I put
little scripts called 'duplicate_oids' and 'find_oid' in
include/catalog that help to find and remove duplicate OID's.
I also moved 'unused_oids' from backend/catalog to
include/catalog, since it has to be in the same directory
as the include files in order to work.
* The backend tries converting the name of a function or aggregate
to all lowercase if the original name given doesn't work (mostly
for compatibility with ODBC).
* You can 'SELECT NULL' to your heart's content.
* I put my _bt_updateitem fix in instead, which uses
_bt_insertonpg so that even if the new key is so big that
the page has to be split, everything still works.
* All literal references to system catalog OID's have been
replaced with references to define'd constants from the catalog
header files.
* I added a couple of node copy functions. I think this was a
preliminary attempt to get rules to work.
Marc G. Fournier
Bruce Momjian
PostgreSQL Daemon
Vadim B. Mikheev
Thomas G. Lockhart
Bryan Henderson