error handling, and simplifies the code that remains. Apparently,
the code that left Berkeley had a whole "error handling subsystem",
which exceptions and whatnot. Since we don't use that anymore,
there's no reason to keep it around.
The regression tests pass with the patch applied. Unless anyone
sees a problem, please apply.
Neil Conway
has_language_privilege, has_schema_privilege to let SQL queries test
all the new privilege types in 7.3. Also, add functions pg_table_is_visible,
pg_type_is_visible, pg_function_is_visible, pg_operator_is_visible,
pg_opclass_is_visible to test whether objects contained in schemas are
visible in the current search path. Do some minor cleanup to centralize
accesses to pg_database, as well.
to behave according to SQL92 (or according to my current understanding
of same, anyway). Per pghackers discussion way back in March 2002:
thread 'Do FROM items of different schemas conflict?'
offset past the last-used-item-plus-one, since that would result in
leaving uninitialized holes in the item pointer array. AFAICT the only
place that was depending on this was btree index build, which was being
cavalier about when to fill in the P_HIKEY pointer; easily fixed.
Also a small performance improvement: shuffle itemid's by means of
memmove, not a one-at-a-time loop.
>> alias in this case. What do you think?
>
> I guess that would make sense. I'll make a separate patch just for
that
> change if that's OK.
>
Simple change -- patch attached.
test=# select * from myfoo1() as z;
z
----
1
2
3
(3 rows)
Joe Conway
don't return type RECORD. It also catches a core dump condition when a
function returning RECORD had an alias list instead of a coldeflist.
Now both conditions throw an ERROR.
Joe Conway
executed in an implicitely aborted transaction (e.g. after an occur
occurs), we return an error (and not just a warning). For example:
nconway=# begin;
BEGIN
nconway=# insert; -- syntax error
ERROR: parser: parse error at or near ";"
nconway=# select * from a;
ERROR: current transaction is aborted, queries ignored until end of
transaction block
The old behavior was:
nconway=# begin;
BEGIN
nconway=# insert;
ERROR: parser: parse error at or near ";"
nconway=# select * from a;
WARNING: current transaction is aborted, queries ignored until end
of transaction block
*ABORT STATE*
Which can be confusing: if the client isn't paying careful attention,
they will conclude that the query has executed (because no error is
returned).
Neil Conway
The local buffer manager is no longer used for newly-created relations
(unless they are TEMP); a new non-TEMP relation goes through the shared
bufmgr and thus will participate normally in checkpoints. But TEMP relations
use the local buffer manager throughout their lifespan. Also, operations
in TEMP relations are not logged in WAL, thus improving performance.
Since it's no longer necessary to fsync relations as they move out of the
local buffers into shared buffers, quite a lot of smgr.c/md.c/fd.c code
is no longer needed and has been removed: there's no concept of a dirty
relation anymore in md.c/fd.c, and we never fsync anything but WAL.
Still TODO: improve local buffer management algorithms so that it would
be reasonable to increase NLocBuffer.
hardwired lists of index names for each catalog, use the relcache's
mechanism for caching lists of OIDs of indexes of any table. This
reduces the common case of updating system catalog indexes to a single
line, makes it much easier to add a new system index (in fact, you
can now do so on-the-fly if you want to), and as a nice side benefit
improves performance a little. Per recent pghackers discussion.
of functions returning domain types, update documentation for typtype,
move get_typtype to lsyscache.c (actually, resurrect the old version),
add defense against creating pseudo-typed table columns, fix some
bogus list-parsing in grammar. Issues remain with respect to alias
handling and type checking; Joe is on those.
types for Table Functions, as previously proposed on HACKERS. Here is a
brief explanation:
1. Creates a new pg_type typtype: 'p' for pseudo type (currently either
'b' for base or 'c' for catalog, i.e. a class).
2. Creates new builtin type of typtype='p' named RECORD. This is the
first of potentially several pseudo types.
3. Modify FROM clause grammer to accept:
SELECT * FROM my_func() AS m(colname1 type1, colname2 type1, ...)
where m is the table alias, colname1, etc are the column names, and
type1, etc are the column types.
4. When typtype == 'p' and the function return type is RECORD, a list
of column defs is required, and when typtype != 'p', it is
disallowed.
5. A check was added to ensure that the tupdesc provide via the parser
and the actual return tupdesc match in number and type of
attributes.
When creating a function you can do:
CREATE FUNCTION foo(text) RETURNS setof RECORD ...
When using it you can do:
SELECT * from foo(sqlstmt) AS (f1 int, f2 text, f3 timestamp)
or
SELECT * from foo(sqlstmt) AS f(f1 int, f2 text, f3 timestamp)
or
SELECT * from foo(sqlstmt) f(f1 int, f2 text, f3 timestamp)
Included in the patches are adjustments to the regression test sql and
expected files, and documentation.
p.s.
This potentially solves (or at least improves) the issue of builtin
Table Functions. They can be bootstrapped as returning RECORD, and
we can wrap system views around them with properly specified column
defs. For example:
CREATE VIEW pg_settings AS
SELECT s.name, s.setting
FROM show_all_settings()AS s(name text, setting text);
Then we can also add the UPDATE RULE that I previously posted to
pg_settings, and have pg_settings act like a virtual table, allowing
settings to be queried and set.
Joe Conway
Can now do queries of the form: SELECT value IS OF (integer, float8);
Define macros for handling typmod manipulation for date/time types.
Should be more robust than all of that brute-force inline code.
Rename macros for masking and typmod manipulation to put TIMESTAMP_
or INTERVAL_ in front of the macro name, to reduce the possibility
of name space collisions.
Allow bit string constants without fully-specified length declaration.
Try implementing CREATE TABLE/OF as a mapping to inheritance.
May be appropriate, or may be replace later with something more exactly
like one might expect from databases without the feature.
strings. Should go back in and look at doing this a bit more elegantly
and (hopefully) cheaper. Probably not too bad anyway, but it seems a
shame to scan the strings twice: once for length for this buffer overrun
protection, and once to parse the line.
Remove use of pow() in date/time handling; was already gone from everything
*but* the time data types.
Define macros for handling typmod manipulation for date/time types.
Should be more robust than all of that brute-force inline code.
Rename macros for masking and typmod manipulation to put TIMESTAMP_
or INTERVAL_ in front of the macro name, to reduce the possibility
of name space collisions.
May not be the long-term solution (some continuing discussion with
Peter E.) but better than the current mapping of a conversion to integer
which I'd put in years ago before we had any bit string types at all.
This is already supported in the bit string implementation elsewhere.
ERROR: ExecInsert: rejected due to CHECK constraint insert_con
To be like this:
ERROR: ExecInsert: rejected due to CHECK constraint "insert_con" on
"insert_tbl"
Updated regression tests to match.
I got sick of seeing 'rejected due to CHECK constraint "$1" in my log and
not being able to find the bug in our website code...
Christopher Kings-Lynne
functionality of the command is basically identical to that of
BEGIN; it just accepts a few extra options (only one of which
PostgreSQL currently implements), and is standards-compliant.
The patch includes a simple regression test and documentation.
[ Regression tests removed, per Peter.]
Neil Conway
in the relcache. It's rather silly that we have reference count leak
checks in bufmgr and in catcache, but not in relcache which will normally
have many fewer entries. Chris K-L would have caught at least one bug
in his recent DROP patch if he'd had this.
relation being modified. In most paths of control we'd already have
such a lock, but if we were dropping the default due to a cascaded
delete of some function it depended on, maybe not.
code review by Tom Lane. Remaining issues: functions that take or
return tuple types are likely to break if one drops (or adds!)
a column in the table defining the type. Need to think about what
to do here.
Along the way: some code review for recent COPY changes; mark system
columns attnotnull = true where appropriate, per discussion a month ago.
attstattarget to indicate 'use the default'. The default is now a GUC
variable default_statistics_target, and so may be changed on the fly. Along
the way we gain the ability to have pg_dump dump the per-column statistics
target when it's not the default. Patch by Neil Conway, with some kibitzing
from Tom Lane.
'tioga recipes', whatever those are -- Peter E. killed most
of it a couple days ago, but this patch removes the rest. Most
of it was #ifdef'ed out anyway.
Neil Conway
The attached patch completes the following TODO item:
* Generate failure on short COPY lines rather than pad NULLs
I also restructed a lot of the existing COPY code, did some code
review on the column list patch sent in by Brent Verner a little
while ago, and added some regression tests. I also added an
explicit check (and resultant error) for extra data before
the end-of-line.
Neil Conway
Bruce Momjian
Tom Lane
Peter Eisentraut
Tatsuo Ishii
Thomas G. Lockhart