Here's the multibyte aware version of my patch to fix the truncation
of the rulename autogenerated during a CREATE VIEW. I've modified all
the places in the backend that want to construct the rulename to use
the MakeRetrieveViewRuleName(), where I put the #ifdef MULTIBYTE, so
that's the only place that knows how to construct a view rulename. Except
pg_dump, where I replicated the code, since it's a standalone binary.
The only effect the enduser will see is that views with names len(name)
> NAMEDATALEN-4 will fail to be created, if the derived rulename clases
with an existing rule: i.e. the user is trying to create two views with
long names whose first difference is past NAMEDATALEN-4 (but before
NAMEDATALEN: that'll error out after the viewname truncation.) In no
case will the user get left with a table without a view rule, as the
current code does.
Ross Reedstrom
user is now defined in terms of the user id, the user name is only computed
upon request (for display purposes). This is kind of the opposite of the
previous state, which would maintain the user name and compute the user id
for permission checks.
Besides perhaps saving a few cycles (integer vs string), this now creates a
single point of attack for changing the user id during a connection, for
purposes of "setuid" functions, etc.
didn't hear anything about, but which would
have broken with the function manager changes
anyway.
Well, this patch checks that a unique constraint
of some form (unique or pk) is on the referenced
columns of an FK constraint and that the columns
in the referencing table exist at creation time.
The former is to move closer to SQL compatibility
and the latter is in answer to a bug report.
I also added a basic check of this functionality
to the alter table and foreign key regression
tests.
Stephan Szabo
sszabo@bigpanda.com
length is < TOAST_TUPLE_THRESHOLD, even with toastable column types
present. For example, CREATE TABLE foo (f1 int, f2 varchar(100))
does not require a toast table, even though varchar is a toastable
type.
right circumstances a hash join executed as a DECLARE CURSOR/FETCH
query would crash the backend. Problem as seen in current sources was
that the hash tables were stored in a context that was a child of
TransactionCommandContext, which got zapped at completion of the FETCH
command --- but cursor cleanup executed at COMMIT expected the tables
to still be valid. I haven't chased down the details as seen in 7.0.*
but I'm sure it's the same general problem.
macros where appropriate (the code used to have several different ways
of doing that, including Int32, Int8, UInt8, ...). Remove last few
references to float32 and float64 typedefs --- it's all float4/float8
now. The typedefs themselves should probably stay in c.h for a release
or two, though, to avoid breaking user-written C functions.
including utility statements. Still can't copy or compare executor
state, but at present that doesn't seem to be necessary. This makes
it possible to execute most (all?) utility statements in plpgsql.
Had to change parsetree representation of CreateTrigStmt so that it
contained only legal Nodes, and not bare string constants.
that giving pg_proc a toast table required solving the same problems
we'd have to solve for pg_class --- pg_proc is one of the relations
that gets bootstrapped in relcache.c. Solution is to go back at the
end of initialization and read in the *real* pg_class row to replace
the phony entry created by formrdesc(). This should work as long as
there's no need to touch any toasted values during initialization,
which seems a reasonable assumption.
Although I did not add a toast-table for every single system table
with a varlena attribute, I believe that it would work to just do
ALTER TABLE pg_class CREATE TOAST TABLE. So anyone who's really
intent on having several thousand ACL entries for a rel could do it.
NOTE: I didn't force initdb, but you must do one to see the effects
of this patch.
thing when there are multiple result relations. Formerly, during
something like 'UPDATE foo*', foo's constraints and *only* foo's
constraints would be applied to all foo's children. Wrong-o ...
trying to toast tuples inserted into toast tables! Fix is two-pronged:
first, ensure all columns of a toast table are marked attstorage='p',
and second, alter the target chunk size so that it's less than the
threshold for trying to toast a tuple. (Code tried to do that but the
expression was wrong.) A few cosmetic cleanups in tuptoaster too.
NOTE: initdb forced due to change in toaster chunk-size.
These two routines will now ALWAYS elog() on failure, whether you ask for
a lock or not. If you really want to get a NULL return on failure, call
the new routines heap_open_nofail()/heap_openr_nofail(). By my count there
are only about three places that actually want that behavior. There were
rather more than three places that were missing the check they needed to
make under the old convention :-(.
At this point I think it'd be possible to make float4 be pass-by-value
without too much work --- and float8 too on machines where Datum is
8 bytes. Something to try when the mood strikes, anyway.
I did not force. I marked numeric as compressable-but-not-move-off-able,
partly to test that storage mode and partly because I've got doubts
that numerics are large enough to need external storage.
Remove a bunch of crufty code for large-object-based arrays, which is
superseded by TOAST and likely hasn't worked in a long time anyway.
Clean up array code a little, and in particular eliminate its habit
of scribbling on the input array (ie, modifying the input tuple :-().
There's now only one transition value and transition function.
NULL handling in aggregates is a lot cleaner. Also, use Numeric
accumulators instead of integer accumulators for sum/avg on integer
datatypes --- this avoids overflow at the cost of being a little slower.
Implement VARIANCE() and STDDEV() aggregates in the standard backend.
Also, enable new LIKE selectivity estimators by default. Unrelated
change, but as long as I had to force initdb anyway...
AlterTableAddConstraint. The major changes from the last patch
are that it should hopefully check for references to temp tables
(not in the shadow case, but at defination time) from permanent tables in
foreign keys and refuse them and that it doesn't allow the table(s)
being constrained to be views (because those cases don't currently
work).
Stephan SzaboThis should be a slighly more complete patch for commands/command.c
AlterTableAddConstraint. The major changes from the last patch
are that it should hopefully check for references to temp tables
(not in the shadow case, but at defination time) from permanent tables in
foreign keys and refuse them and that it doesn't allow the table(s)
being constrained to be views (because those cases don't currently
work).
Stephan Szabo
pass-by-ref data types --- eg, an index on lower(textfield) --- no longer
leak memory during index creation or update. Clean up a lot of redundant
code ... did you know that copy, vacuum, truncate, reindex, extend index,
and bootstrap each basically duplicated the main executor's logic for
extracting information about an index and preparing index entries?
Functional indexes should be a little faster now too, due to removal
of repeated function lookups.
CREATE INDEX 'opt_type' clause is deimplemented by these changes,
but I haven't removed it from the parser yet (need to merge with
Thomas' latest change set first).
memory contexts. Currently, only leaks in expressions executed as
quals or projections are handled. Clean up some old dead cruft in
executor while at it --- unused fields in state nodes, that sort of thing.
backend functions via backend PQexec(). The SPI interface has long
been our only documented way to do this, and the backend pqexec/portal
code is unused and suffering bit-rot. I'm putting it out of its misery.
Special handling of TOAST relations during VACUUM. TOAST relations
are vacuumed while the lock on the master table is still active.
The ANALYZE flag doesn't propagate to their vacuuming because the
toaster access routines allways use index access ignoring stats, so
why compute them at all.
Protection of TOAST relations against normal INSERT/UPDATE/DELETE
while offering SELECT for debugging purposes.
Jan
Don't go through pg_exec_query_dest(), but directly to the execution
routines. Also, extend parameter lists so that there's no need to
change the global setting of allowSystemTableMods, a hack that was
certain to cause trouble in the event of any error.
entry that has rules. This allows us to release the rule parsetrees
on relcache flush without needing a working freeObject() routine.
Formerly, the rule trees were leaked permanently at relcache flush.
Also, clean up handling of rule creation and deletion --- there was
not sufficient locking of the relation being modified, and there was
no reliable notification of other backends that a relcache reload
was needed. Also, clean up relcache.c code so that scans of system
tables needed to load a relcache entry are done in the caller's
memory context, not in CacheMemoryContext. This prevents any
un-pfreed memory from those scans from becoming a permanent memory
leak.
for details). It doesn't really do that much yet, since there are no
short-term memory contexts in the executor, but the infrastructure is
in place and long-term contexts are handled reasonably. A few long-
standing bugs have been fixed, such as 'VACUUM; anything' in a single
query string crashing. Also, out-of-memory is now considered a
recoverable ERROR, not FATAL.
Eliminate a large amount of crufty, now-dead code in and around
memory management.
Fix problem with holding off SIGTRAP, SIGSEGV, etc in postmaster and
backend startup.
option settings. Sort out SIGHUP vs BACKEND -- there is no total ordering
here, so make explicit checks. Add comments explaining all of this.
Removed permissions check on SHOW command.
Add examine_subclass to the game, rename to SQL_inheritance to fit the
official data model better. Adjust documentation.
Standalone backend needs to reset all options before it starts. To
facilitate that, have IsUnderPostmaster be set by the postmaster itself,
don't wait for the magic -p switch.
Also make sure that all environment variables and argv's survive
init_ps_display(). Use strdup where necessary.
Have initdb make configuration files (postgresql.conf, pg_hba.conf) mode
0600 -- having configuration files is no fun if you can't edit them.
materialized tupleset is small enough) instead of a temporary relation.
This was something I was thinking of doing anyway for performance, and Jan
says he needs it for TOAST because he doesn't want to cope with toasting
noname relations. With this change, the 'noname table' support in heap.c
is dead code, and I have accordingly removed it. Also clean up 'noname'
plan handling in planner --- nonames are either sort or materialize plans,
and it seems less confusing to handle them separately under those names.
passing the index-is-unique flag to index build routines (duh! ...
why wasn't it done this way to begin with?). Aside from eliminating
an eyesore, this should save a few milliseconds in btree index creation
because a full scan of pg_index is not needed any more.
discussion of 5/19/00). pg_index is now searched for indexes of a
relation using an indexscan. Moreover, this is done once and cached
in the relcache entry for the relation, in the form of a list of OIDs
for the indexes. This list is used by the parser and executor to drive
lookups in the pg_index syscache when they want to know the properties
of the indexes. Net result: index information will be fully cached
for repetitive operations such as inserts.
