Bruce Momjian [Mon, 23 Sep 2002 01:51:02 +0000 (01:51 +0000)]
The valid return value should be MODIFY instead of MODIFIED.
The error message said so :-)
In 25.3. Using PL/Python
If the trigger "when" is BEFORE, you may return None or "OK"
from the Python function to indicate the tuple is unmodified, "SKIP"
to abort the event, or "MODIFIED" to indicate you've modified the tuple.
should read
If the trigger "when" is BEFORE, you may return None or "OK"
from the Python function to indicate the tuple is unmodified, "SKIP"
to abort the event, or "MODIFY" to indicate you've modified the tuple.
Bruce Momjian [Mon, 23 Sep 2002 01:43:23 +0000 (01:43 +0000)]
Obviously noone has ever tested the doubling of availiable result ids
up to
reaching the hard limit. After opening 16(=current REST_START value)
results via pg_exec, the next pg_exec tries to find an empty slot
forever :-( . In PgSetResultId file pgtclId.c in the for loop there
has to be done a break, if res_max ist reached. The piece of code
should look like
if (resid == connid->res_max)
{
resid = 0;
break; /* the break as to be added */
}
now everything works (double available results after reaching
RES_START up to reaching RES_HARD_MAX)
Tom Lane [Mon, 23 Sep 2002 00:42:48 +0000 (00:42 +0000)]
Get rid of bogus use of heap_mark4update in reindex operations (cf.
recent bug report). Fix processing of nailed-in-cache indexes;
it appears that REINDEX DATABASE has been broken for months :-(.
Tom Lane [Sun, 22 Sep 2002 23:03:58 +0000 (23:03 +0000)]
In UpdateStats(), don't bother to update the pg_class row if it already
contains the correct statistics. This is a partial solution for the
problem of allowing concurrent CREATE INDEX commands: unless they commit
at nearly the same instant, the second one will see the first one's
pg_class updates as committed, and won't try to update again, thus
avoiding the 'tuple concurrently updated' failure.
Tom Lane [Sun, 22 Sep 2002 20:56:28 +0000 (20:56 +0000)]
RelationClearRelation must reset rd_targblock and update rd_nblocks
even when dealing with a nailed-in-cache relation; otherwise, following
VACUUM truncation of a system catalog, other backends might have
unreasonably large values of these fields.
Tom Lane [Sun, 22 Sep 2002 20:08:51 +0000 (20:08 +0000)]
I haven't seen any objections, so here is a patch. It removes "#define
YYERROR_VERBOSE" from contrib/cube and contrib/seg, and adjusts the expected
output accordingly. Hopefully this will consistently pass across multiple
bison versions.
Tom Lane [Sun, 22 Sep 2002 19:42:52 +0000 (19:42 +0000)]
Replace pg_attribute.attisinherited with attislocal and attinhcount
columns, to allow more correct behavior in multiple-inheritance cases.
Patch by Alvaro Herrera, review by Tom Lane.
Tom Lane [Sun, 22 Sep 2002 17:27:25 +0000 (17:27 +0000)]
Bring SIMILAR TO and SUBSTRING into some semblance of conformance with
the SQL99 standard. (I'm not sure that the character-class features are
quite right, but that can be fixed later.) Document SQL99 and POSIX
regexps as being different features; provide variants of SUBSTRING for
each.
Tom Lane [Sun, 22 Sep 2002 00:37:09 +0000 (00:37 +0000)]
Move most of the error checking for foreign-key constraints out of
parse analysis and into the execution code (in tablecmds.c). This
eliminates a lot of unreasonably complex code that needed to have two
or more execution paths in case it was dealing with a not-yet-created
table column vs. an already-existing one. The execution code is always
dealing with already-created tables and so needs only one case. This
also eliminates some potential race conditions (the table wasn't locked
between parse analysis and execution), makes it easy to fix the gripe
about wrong referenced-column names generating a misleading error message,
and lets us easily add a dependency from the foreign-key constraint to
the unique index that it requires the referenced table to have. (Cf.
complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.)
Also, third try at building a deletion mechanism that is not sensitive
to the order in which pg_depend entries are visited. Adding the above-
mentioned dependency exposed the folly of what dependency.c had been
doing: it failed for cases where B depends on C while both auto-depend
on A. Dropping A should succeed in this case, but was failing if C
happened to be visited before B. It appears the only solution is two
separate walks over the dependency tree.
Tom Lane [Sat, 21 Sep 2002 18:39:26 +0000 (18:39 +0000)]
Provide an upgrade strategy for dump files containing functions declared
with OPAQUE. CREATE LANGUAGE, CREATE TRIGGER, and CREATE TYPE will all
accept references to functions declared with OPAQUE --- but they will
issue a NOTICE, and will modify the function entries in pg_proc to have
the preferred type-safe argument or result types instead of OPAQUE.
Per recent pghackers discussions.
Tom Lane [Fri, 20 Sep 2002 19:56:01 +0000 (19:56 +0000)]
Performance improvement for MultiRecordFreeSpace on large relations ---
avoid O(N^2) behavior. Problem noted and fixed by Stephen Marshall <smarshall@wsicorp.com>,
with some help from Tom Lane.
Tom Lane [Fri, 20 Sep 2002 16:56:02 +0000 (16:56 +0000)]
Code review for check-domain-constraints-in-COPY patch. Do correct thing
when default expression for a domain is being used. Avoid repetitive
catalog lookups.
Bruce Momjian [Fri, 20 Sep 2002 03:55:40 +0000 (03:55 +0000)]
Tom Lane wrote:
> I see in your recent bytea-LIKE patch
>
> if (datatype != BYTEAOID && pg_database_encoding_max_length()
> 1)
> len = pg_mbcliplen((const unsigned char *) workstr, len,
len - 1);
> else
> len -= -1;
>
> Surely there's one too many minus signs in that last?
Bruce Momjian [Fri, 20 Sep 2002 03:54:57 +0000 (03:54 +0000)]
This patch cleans up some of the code in src/util/adt/formatting.c,
fixes a few minor bugs (typos, potential buffer overruns, etc.), and
fixes some spelling/grammar mistakes.
Bruce Momjian [Fri, 20 Sep 2002 03:47:22 +0000 (03:47 +0000)]
I have included fixes to declare some floating point constants as double
instead of int, change the calculation method to use the haversine
formula
which is more accurrate for short distances, added a grant to public for
geo_distance and added a regression test.
I will resubmit the earth distance stuff based on cube after 7.3 is
released.
Bruce Momjian [Fri, 20 Sep 2002 03:45:08 +0000 (03:45 +0000)]
> I'm not sure why NDirectFileRead/NDirectFileWrite are unused at the
> moment, but they used to be used; I think the correct response is to
> put back the missing counter increments, not rip out the counters.
Ok, fair enough. It's worth noting that they've been broken for a
while -- for example, the HashJoin counter increments were broken when
you comitted r1.20 of executor/nodeHashJoin.c in May of '99.
I've attached a revised patch that doesn't remove the counters (but
doesn't increment them either: I'm not sure of all the places where
the counter should be incremented).
Bruce Momjian [Fri, 20 Sep 2002 03:39:15 +0000 (03:39 +0000)]
This patch corrects a minor mis-statement in the CREATE DOMAIN docs,
pointed out by Chris KL on -hackers a little while ago -- NOT NULL !=
CHECK xxx IS NOT NULL.
Tom Lane [Thu, 19 Sep 2002 23:40:56 +0000 (23:40 +0000)]
Tweak heap.c to refuse attempts to create table columns of standalone
composite types. Add a couple more lsyscache.c routines to support this,
and make use of them in some other places that were doing lookups the
hard way.
Tom Lane [Thu, 19 Sep 2002 22:48:34 +0000 (22:48 +0000)]
Department of second thoughts: suppressing implicit casts everywhere in
ruleutils display is not such a great idea. For arguments of functions
and operators I think we'd better keep the historical behavior of showing
such casts explicitly, to ensure that the function/operator is reparsed
the same way when the rule is reloaded. This also makes the output of
EXPLAIN less obscurantist about exactly what's happening.
Tom Lane [Wed, 18 Sep 2002 21:35:25 +0000 (21:35 +0000)]
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
Tom Lane [Mon, 16 Sep 2002 01:24:41 +0000 (01:24 +0000)]
Fix for rare race-condition-like failure: if a backend receives SIGUSR2
(notify/SI-overrun interrupt) while it is in process of doing proc_exit,
it is possible for Async_NotifyHandler() to try to start a transaction
when one is already running. This leads to Asserts() or worse. I think
it may only be possible to occur when frontend synchronization is lost
(ie, the elog(FATAL) in SocketBackend() fires), but that is a standard
occurrence after error during COPY. In any case, I have seen this
failure occur during regression tests, so it is definitely possible.
Tom Lane [Sat, 14 Sep 2002 20:28:54 +0000 (20:28 +0000)]
The attached adds GRANTs to PUBLIC for dblink functions, removes the
non-standard regression test, and adds standard installcheck regression test
support.
The test creates a second database (regression_slave) and drops it again, in
order to avoid the cheesy-ness of connecting back to the same database ;-)
Tom Lane [Sat, 14 Sep 2002 19:53:59 +0000 (19:53 +0000)]
Attached is a patch to fix some recently raised issues that exist in
contrib/tablefunc. Specifically it replaces the use of VIEWs (for needed
composite type creation) with use of CREATE TYPE. It also performs GRANT
EXECUTE ON FUNCTION foo() TO PUBLIC for all of the created functions. There
was also a cosmetic change to two regression files.
Tom Lane [Thu, 12 Sep 2002 21:16:42 +0000 (21:16 +0000)]
Fix likely cause of rare ALTER TABLE ADD FOREIGN KEY failures ---
don't assume relname field of a relcache entry will stay valid across
lots of operations.
Bruce Momjian [Thu, 12 Sep 2002 00:26:42 +0000 (00:26 +0000)]
The small context diff below corrects what seems to be an oversight in
fmgr.h - it's discouraged to access fcinfo directly but there is no
macro to get the number of arguments passed to the function. Checking
the number of arguments is often useful when you have a function which
can be called like:
func('arg');
func(null);
func();
all mapping to the same C function.
the macro has a function-like appearance to match the other PG_*
macros.
Bruce Momjian [Thu, 12 Sep 2002 00:26:00 +0000 (00:26 +0000)]
This is a comprehensive set of diffs (versus current CVS) that replaces those
attached to the same message with the Earth Distance patches.
Recent changes include changing the subscript in one place I forgot
in the previous bugfix patch. A couple of added regression tests, which
should help catch this mistake if it reappears.
I also put in a limit of 100 dimensions in cube_large and cube_in to
prevent making it easy to create very large cubes. Changing one define
in cubedata.h will raise the limit if some needs more dimensions.
Bruce Momjian [Thu, 12 Sep 2002 00:24:46 +0000 (00:24 +0000)]
> intarray and ltree both seem to be mapping their own declarations onto
> arrays using largely-similar code. But while intarray fails its
> regression test, I find ltree still passes. So I'm confused about what
> that code is really doing and don't want to touch it.
Please, apply attached patch, it solves the problem.
Bruce Momjian [Thu, 12 Sep 2002 00:24:10 +0000 (00:24 +0000)]
> Sean Chittenden <sean@chittenden.org> writes:
>
>>::sigh:: Is it me or does it look like all
>>of pl/pgsql is schema un-aware (ie, all of the declarations). -sc
>
>
> Yeah. The group of routines parse_word, parse_dblword, etc that are
> called by the lexer certainly all need work. There are some
> definitional issues to think about, too --- plpgsql presently relies on
> the number of names to give it some idea of what to look for, and those
> rules are probably all toast now. Please come up with a sketch of what
> you think the behavior should be before you start hacking code.
Attached is a diff -c format proposal to fix this. I've also attached a short
test script. Seems to work OK and passes all regression tests.
Here's a breakdown of how I understand plpgsql's "Special word rules" -- I
think it illustrates the behavior reasonably well. New functions added by this
patch are plpgsql_parse_tripwordtype and plpgsql_parse_dblwordrowtype:
Bruce Momjian [Thu, 12 Sep 2002 00:21:25 +0000 (00:21 +0000)]
Joe Conway wrote:
> Hannu Krosing wrote:
>
>> It seems that my last mail on this did not get through to the list
>> ;(
>>
>> Please consider renaming the new builtin function
>> split(text,text,int)
>>
>> to something else, perhaps
>>
>> split_part(text,text,int)
>>
>> (like date_part)
>>
>> The reason for this request is that 3 most popular scripting
>> languages (perl, python, php) all have also a function with similar
>> signature, but returning an array instead of single element and the
>> (optional) third argument is limit (maximum number of splits to
>> perform)
>>
>> I think that it would be good to have similar function in (some
>> future release of) postgres, but if we now let in a function with
>> same name and arguments but returning a single string instead an
>> array of them, then we will need to invent a new and not so easy to
>> recognise name for the "real" split function.
>>
>
> This is a good point, and I'm not opposed to changing the name, but
> it is too bad your original email didn't get through before beta1 was
> rolled. The change would now require an initdb, which I know we were
> trying to avoid once beta started (although we could change it
> without *requiring* an initdb I suppose).
>
> I guess if we do end up needing an initdb for other reasons, we
> should make this change too. Any other opinions? Is split_part an
> acceptable name?
>
> Also, if we add a todo to produce a "real" split function that
> returns an array, similar to those languages, I'll take it for 7.4.
No one commented on the choice of name, so the attached patch changes
the name of split(text,text,int) to split_part(text,text,int) per
Hannu's recommendation above. This can be applied without an initdb if
current beta testers are advised to run:
update pg_proc set proname = 'split_part' where proname = 'split';
in the case they want to use this function. Regression and doc fix is
also included in the patch.
Bruce Momjian [Thu, 12 Sep 2002 00:19:44 +0000 (00:19 +0000)]
> Now I'm testing connectby() in the /contrib/tablefunc in 7.3b1, which would
> be a useful function for many users. However, I found the fact that
> if connectby_tree has the following data, connectby() tries to search the end
> of roots without knowing that the relations are infinite(-5-9-10-11-9-10-11-)
.
> I hope connectby() supports a check routine to find infinite relations.
>
>
> CREATE TABLE connectby_tree(keyid int, parent_keyid int);
> INSERT INTO connectby_tree VALUES(1,NULL);
> INSERT INTO connectby_tree VALUES(2,1);
> INSERT INTO connectby_tree VALUES(3,1);
> INSERT INTO connectby_tree VALUES(4,2);
> INSERT INTO connectby_tree VALUES(5,2);
> INSERT INTO connectby_tree VALUES(6,4);
> INSERT INTO connectby_tree VALUES(7,3);
> INSERT INTO connectby_tree VALUES(8,6);
> INSERT INTO connectby_tree VALUES(9,5);
>
> INSERT INTO connectby_tree VALUES(10,9);
> INSERT INTO connectby_tree VALUES(11,10);
> INSERT INTO connectby_tree VALUES(9,11); <-- infinite
>
The attached patch fixes the infinite recursion bug in
contrib/tablefunc/tablefunc.c:connectby found by Masaru Sugawara.
I implemented it by checking the branch string for repeated keys
(whether or not the branch is returned). The performance hit was pretty
minimal -- about 1% for a moderately complex test case (220000 record
table, 9 level tree with 3800 members).
Bruce Momjian [Thu, 12 Sep 2002 00:18:14 +0000 (00:18 +0000)]
> BTW, clusterdb is not schema-aware and will surely fail in any database
> where more than one schema is in use, because it doesn't trouble to
> schema-qualify table names.
Ok, the following patch should solve this concern. It also tries to
connect as little times as possible (the previous one would connect one
time per table plus one per database; this one connects two times per
database).
Bruce Momjian [Thu, 12 Sep 2002 00:15:33 +0000 (00:15 +0000)]
The attached small patch fixes the cause of the regression test failure
for contrib/intarray.
The cause was that the library uses its own function to construct a new
array, new_intArrayType, and that function did not set the new array
struct attribute elemtype.
Bruce Momjian [Thu, 12 Sep 2002 00:14:40 +0000 (00:14 +0000)]
The attached removes the current non-standard file
"contrib/tablefunc/tablefunc-test.sql", and adds a standard regression
test suite to contrib/tablefunc.
Tom Lane [Wed, 11 Sep 2002 14:48:55 +0000 (14:48 +0000)]
Tweak querytree-dependency-extraction code so that columns of tables
that are explicitly JOINed are not considered dependencies unless they
are actually used in the query: mere presence in the joinaliasvars
list of a JOIN RTE doesn't count as being used. The patch touches
a number of files because I needed to generalize the API of
query_tree_walker to support an additional flag bit, but the changes
are otherwise quite small.
Barry Lind [Wed, 11 Sep 2002 05:38:45 +0000 (05:38 +0000)]
Patches submitted by Kris Jurka (jurka@ejurka.com) for the following bugs:
- Properly drop tables in jdbc regression tests with cascade for 7.3
- problem with Statement.execute() and executeUpdate() not clearing binds
- problem with ResultSet not correctly handling default encoding
- changes to correctly support show transaction isolation level in 7.3
- changed DatabaseMetaDataTest to handle differences in FK names in 7.3
- better fix for dynamically checking server NAME data length
(With the fixes above the jdbc regression tests pass on jdbc2 and jdbc3
against both a 7.2 and 7.3 server)
Patchs submitted by David Wall (d.wall@computer.org):
- problem with getBlob when largeobject oid is null
- improvements to BlobOutputStream
Patch submitted by Haris Peco (snpe@snpe.co.yu):
- problem with callable statement not supporting prepared statement methods