summaryrefslogtreecommitdiff
path: root/src/backend/commands
Commit message (Collapse)AuthorAgeFilesLines
...
* Rename rule CURRENT to OLD in source tree. Add mapping for backwardBruce Momjian2000-06-121-5/+5
| | | | compatiblity with old rules.
* Back out pg_shadow changes to allow create table and locking permissions.Bruce Momjian2000-06-123-72/+7
|
* Update sequence-related functions to new fmgr style. Remove downcasing,Tom Lane2000-06-111-23/+83
| | | | | | | | quote-stripping, and acl-checking tasks for these functions from the parser, and do them at function execution time instead. This fixes the failure of pg_dump to produce correct output for nextval(Foo) used in a rule, and also eliminates the restriction that the argument of these functions must be a parse-time constant.
* I have large database and with this DB work more users and I very needBruce Momjian2000-06-093-7/+72
| | | | | | | | | | | | | | | | | | | | | | | | more restriction for fretful users. The current PG allow define only NO-CREATE-DB and NO-CREATE-USER restriction, but for some users I need NO-CREATE-TABLE and NO-LOCK-TABLE. This patch add to current code NOCREATETABLE and NOLOCKTABLE feature: CREATE USER username [ WITH [ SYSID uid ] [ PASSWORD 'password' ] ] [ CREATEDB | NOCREATEDB ] [ CREATEUSER | NOCREATEUSER ] -> [ CREATETABLE | NOCREATETABLE ] [ LOCKTABLE | NOLOCKTABLE ] ...etc. If CREATETABLE or LOCKTABLE is not specific in CREATE USER command, as default is set CREATETABLE or LOCKTABLE (true). A user with NOCREATETABLE restriction can't call CREATE TABLE or SELECT INTO commands, only create temp table is allow for him. Karel
* Inheritance overhaul by Chris Bitmead <chris@bitmead.com>Bruce Momjian2000-06-092-3/+95
|
* Another round of updates for new fmgr, mostly in the datetime code.Tom Lane2000-06-091-5/+7
|
* Mark functions as static and ifdef NOT_USED as appropriate.Bruce Momjian2000-06-083-7/+8
|
* Re-order pg_listener index so it can later be used in an index scan.Bruce Momjian2000-06-071-24/+9
|
* Update for 7.0.2.Bruce Momjian2000-06-051-2/+2
|
* Latest round of fmgr updates. All functions with bool,char, or int2Tom Lane2000-06-052-4/+7
| | | | | | | inputs have been converted to newstyle. This should go a long way towards fixing our portability problems with platforms where char and short parameters are passed differently from int-width parameters. Still more to do for the Alpha port however.
* Disallow CLOSE of reserved system portal names.Tom Lane2000-06-041-1/+6
|
* New ps display code, works on more platforms.Peter Eisentraut2000-06-041-3/+3
| | | | | | Install a default configuration file. Clean up some funny business in the config file code.
* Remove NT-specific file open defines by defining our own open macros forBruce Momjian2000-06-021-12/+3
| | | | "rb" and "wb".
* If create/drop database are going to call closeAllVfds(), they oughtTom Lane2000-06-021-17/+19
| | | | | to do it at the last moment before calling system() ... not at some randomly-chosen earlier point in the routine ...
* Create an fd.c entry point that is just like plain open(2) except thatTom Lane2000-06-021-5/+5
| | | | | | | | | | it will close VFDs if necessary to surmount ENFILE or EMFILE failures. Make use of this in md.c, xlog.c, and user.c routines that were formerly vulnerable to these failures. In particular, this should handle failures of mdblindwrt() that have been observed under heavy load conditions. (By golly, every other process on the system may crash after Postgres eats up all the kernel FDs, but Postgres will keep going!)
* The heralded `Grand Unified Configuration scheme' (GUC)Peter Eisentraut2000-05-312-748/+108
| | | | | | | | | | | | | That means you can now set your options in either or all of $PGDATA/configuration, some postmaster option (--enable-fsync=off), or set a SET command. The list of options is in backend/utils/misc/guc.c, documentation will be written post haste. pg_options is gone, so is that pq_geqo config file. Also removed were backend -K, -Q, and -T options (no longer applicable, although -d0 does the same as -Q). Added to configure an --enable-syslog option. changed all callers from TPRINTF to elog(DEBUG)
* Added header files required for ALTER TABLE DROP COLUMNHiroshi Inoue2000-05-301-1/+6
| | | | trial implementation.
* Third round of fmgr updates: eliminate calls using fmgr() andTom Lane2000-05-302-92/+109
| | | | | fmgr_faddr() in favor of new-style calls. Lots of cleanup of sloppy casts to use XXXGetDatum and DatumGetXXX ...
* Remove unused include files. Do not touch /port or includes used by defines.Bruce Momjian2000-05-309-48/+8
|
* Add analyze.c file for split.Bruce Momjian2000-05-291-0/+635
|
* Split vacuum and analyze into separate filesBruce Momjian2000-05-292-602/+4
|
* Update messages.Bruce Momjian2000-05-291-2/+2
|
* Make analyze do vacuum/analyze in one step.Bruce Momjian2000-05-291-5/+5
|
* More vacuum cleanupBruce Momjian2000-05-291-227/+228
|
* more cleanupBruce Momjian2000-05-291-18/+18
|
* Add analyze log messages for verbose mode.Bruce Momjian2000-05-291-1/+3
|
* cleanupBruce Momjian2000-05-291-7/+1
|
* Allow vacuum to perform analyze with shared lock. Update cvs manual.Bruce Momjian2000-05-291-375/+440
|
* Generated header files parse.h and fmgroids.h are now copied intoTom Lane2000-05-292-15/+4
| | | | | the src/include tree, so that -I backend is no longer necessary anywhere. Also, clean up some bit rot in contrib tree.
* Second round of fmgr changes: triggers are now invoked in new style,Tom Lane2000-05-293-87/+97
| | | | CurrentTriggerData is history.
* More vacuum cleanupsBruce Momjian2000-05-291-17/+17
|
* More vacuum renaming.Bruce Momjian2000-05-291-163/+163
|
* Miscellaneous cleanups of places that needed to account for newTom Lane2000-05-282-9/+13
| | | | pg_language entries.
* First round of changes for new fmgr interface. fmgr itself and theTom Lane2000-05-2811-67/+75
| | | | | | | key call sites are changed, but most called functions are still oldstyle. An exception is that the PL managers are updated (so, for example, NULL handling now behaves as expected in plperl and plpgsql functions). NOTE initdb is forced due to added column in pg_proc.
* Do table renaming in a sane order: physical file rename must happenTom Lane2000-05-251-28/+36
| | | | | | | *last*, after all updating of system catalogs. In old code, an error detected during TypeRename left the relation hosed. Also, add a call to flush the relation's relcache entry, rather than trusting to shared cache invalidation to flush it for us.
* On solaris, createdb/dropdb fails because of strange behavior of system().Tatsuo Ishii2000-05-251-1/+13
| | | | | (it returns error with errno ECHILD upon successful completion of commands). This fix ignores an error from system() if errno == ECHILD.
* Revise FlushRelationBuffers/ReleaseRelationBuffers per discussion withTom Lane2000-05-192-6/+8
| | | | | | | | | | | | | | | | | | | | | Hiroshi. ReleaseRelationBuffers now removes rel's buffers from pool, instead of merely marking them nondirty. The old code would leave valid buffers for a deleted relation, which didn't cause any known problems but can't possibly be a good idea. There were several places which called ReleaseRelationBuffers *and* FlushRelationBuffers, which is now unnecessary; but there were others that did not. FlushRelationBuffers no longer emits a warning notice if it finds dirty buffers to flush, because with the current bufmgr behavior that's not an unexpected condition. Also, FlushRelationBuffers will flush out all dirty buffers for the relation regardless of block number. This ensures that pg_upgrade's expectations are met about tuple on-row status bits being up-to-date on disk. Lastly, tweak BufTableDelete() to clear the buffer's tag so that no one can mistake it for being a still-valid buffer for the page it once held. Formerly, the buffer would not be found by buffer hashtable searches after BufTableDelete(), but it would still be thought to belong to its old relation by the routines that sequentially scan the shared-buffer array. Again I know of no bugs caused by that, but it still can't be a good idea.
* Change remove function warning for built-ins.Bruce Momjian2000-05-181-2/+2
|
* Throw NOTICE on built-in function removalBruce Momjian2000-05-181-2/+2
|
* Reduce COPY IN lock from AccessExclusive to a more reasonableTom Lane2000-05-181-6/+8
| | | | | | | RowExclusive (my fault). Also, install a check to prevent people from trying COPY BINARY to stdout/from stdin. No way that will work unless we redesign the frontend COPY protocol ... which is not worth the trouble in the near future ...
* Finally fix LISTEN problem.Bruce Momjian2000-05-141-1/+10
|
* This is the second time I've answered this exact same problem in twoBruce Momjian2000-05-121-2/+12
| | | | | | | | | | | | | | | | | | | | | days. It seems to be a FAQ, and I think I know why. When creating a 'c' language function, CREATE FUNCTION is fed the shared object filename, and seems to succeed. Only when trying to use the function is an error thrown, by which time the coder thinks something's wrong with executing the code, not with loading it. I think I once saw it proposed to load shared objects at function creation time, but that idea was shot down on the grounds of resident memory bloat, ISTR. Here's a patch for a compromise: all it does is stat() the file, just like the loader code does, so that the errors caused by non existent files, and no directory 'x' permissions (the most common ones, it seems), get caught while the developer is still thinking about code loading. It doesn't catch all errors (like the code not being readable by the postgres user) but seems to catch the most common, without actually opening the file. What do you think? Ross
* Squash some more CLUSTER bugs. Never has worked on multiple-columnTom Lane2000-05-121-5/+18
| | | | | | | | | | | | indexes, apparently, nor on functional indexes with more than one input column (force of natts = 1 was in the wrong branch of IF statement). Coredumped if source relation contained any uncommitted tuples, due to failure to test for success return from heap_fetch. Fetched tuple was passed directly to heap_insert, which clobbers the TID and commit status in the tuple header it's given, which meant that the source relation's tuples all got trashed as the copy proceeded. Abort partway through, and you're left with a lot of missing tuples. I wonder what else is lurking here ...
* Fix CLUSTER ... or at least undo the bit-rot it's suffered since 6.5.Tom Lane2000-05-112-38/+41
| | | | | It's still pretty fundamentally bogus :-(. Freebie side benefit: ALTER TABLE RENAME works on indexes now.
* Don't leak a file descriptor when updating pg_pwd file. Also, check forTom Lane2000-05-041-11/+21
| | | | failure of rename() call.
* change reindex ERROR/NOTICE messageHiroshi Inoue2000-04-251-5/+7
|
* Check that user-specified opclass in CREATE INDEX corresponds to operatorsTom Lane2000-04-251-2/+41
| | | | that will actually work on the column datatype.
* Produce an appropriate error message when opclass is not supported byTom Lane2000-04-231-37/+86
| | | | | specified index access method. Clean up wording of some existing error messages, too.
* Allow COPY WITH OIDS to system OID values --- rely on unique indexes toTom Lane2000-04-161-15/+17
| | | | | prevent duplicate OIDs from being added. Clean up redundant error messages.
* Show failing OID in 'cache lookup failed' messages.Tom Lane2000-04-161-3/+3
|
View Lorry Controller Status