[BUGS] plperl building problem on FreeBSD 4.10 port
Hi, I was installing a brand new PostgreSQL 7.4.6 on FreeBSD 4.10 using ports: portinstall postgresql7 portinstall postgresql-pltcl portinstall p5-postgresql-plperl but when I was going to install the plperl, I've found following error: Nov 27 11:06:51 biblio postgres[93190]: [1-1] ERROR: could not load library "/usr/local/lib/postgresql/plperl.so": dlopen '/usr/local/lib/postgresql/plperl.so' failed. Nov 27 11:06:51 biblio postgres[93190]: [1-2] (/usr/local/lib/postgresql/plperl.so: Undefined symbol "Perl_sv_2pv_flags") bash-2.05b$ createlang plperlu template1 createlang: language installation failed: ERROR: could not load library "/usr/local/lib/postgresql/plperl.so": dlopen '/usr/local/lib/postgresql/plperl.so' failed. (/usr/local/lib/postgresql/plperl.so: Undefined symbol "Perl_sv_2pv_flags") On IRC I've found AndrewSN that helped me: : that's a known build problem : ok, reinstall as follows: in the port dir, do "make patch" (which will unpack and patch the tree) : then modify configure (in the work dir) as follows: : can you find the main "configure" file it should have extracted : about 4300 lines down is this line: : perl_embed_ldflags=`echo X"$pgac_tmp1" | sed "s/^X//;s%$pgac_tmp2%%"` : change that to: : perl_embed_ldflags=`$PERL -MExtUtils::Embed -e ldopts` : then going back to the port dir and doing make; make install should work In this way it works fine. It should be usefull if that simple patch was available for BSD port users. Bye, \fer ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] plpgsql unreachable code (was BUG #1329: Bug in IF-ELSEIF-ELSE construct)
Neil Conway wrote:
(BTW, another thing this example exposes is that we don't issue warnings
about trivially-dead-code, such as statements in a basic block that
follow a RETURN. This would probably be also worth doing.)
Attached is a patch that implements this. Specifically, if there are any
statements in the same block that follow a RETURN, EXIT (without
condition) or RAISE EXCEPTION statement, we issue a warning at CREATE
FUNCTION time:
create function exit_warn() returns int as $$
declare x int;
begin
x := 5;
loop
x := x + 1;
exit;
x := x + 2;
end loop;
x := x + 3;
return x;
end;$$ language 'plpgsql';
WARNING: assignment is unreachable, due to exit near line 6
CONTEXT: compile of PL/pgSQL function "exit_warn" near line 7
No warning is issued if check_function_bodies is false.
AFAICS there is no current infrastructure for walking a PL/PgSQL
function's parse tree, so I did this manually (which is easy enough, of
course). In the future it might be a good idea to refactor this to use
something akin to the "walker" infrastructure in the backend (for one
thing the PL/PgSQL function dumping code could use this as well).
(BTW this patch is intended for 8.1, of course.)
-Neil
--- src/pl/plpgsql/src/pl_comp.c
+++ src/pl/plpgsql/src/pl_comp.c
@@ -130,6 +130,7 @@
static void plpgsql_HashTableInsert(PLpgSQL_function *function,
PLpgSQL_func_hashkey *func_key);
static void plpgsql_HashTableDelete(PLpgSQL_function *function);
+static void check_function(PLpgSQL_function *function);
/*
* This routine is a crock, and so is everyplace that calls it. The problem
@@ -152,8 +153,10 @@
/* --
* plpgsql_compile Make an execution tree for a PL/pgSQL function.
*
- * If forValidator is true, we're only compiling for validation purposes,
- * and so some checks are skipped.
+ * If forValidator is true, we're only compiling for validation
+ * purposes; this means we skip some checks, as well as making some
+ * additional compile-time checks that we only want to do once (at
+ * function definition time), not very time the function is compiled.
*
* Note: it's important for this to fall through quickly if the function
* has already been compiled.
@@ -293,7 +296,7 @@
* Setup error traceback support for ereport()
*/
plerrcontext.callback = plpgsql_compile_error_callback;
- plerrcontext.arg = forValidator ? proc_source : (char *) NULL;
+ plerrcontext.arg = forValidator ? proc_source : NULL;
plerrcontext.previous = error_context_stack;
error_context_stack = &plerrcontext;
@@ -595,7 +598,7 @@
plpgsql_add_initdatums(NULL);
/*
-* Now parse the functions text
+* Now parse the function's text
*/
parse_rc = plpgsql_yyparse();
if (parse_rc != 0)
@@ -605,7 +608,7 @@
pfree(proc_source);
/*
-* If that was successful, complete the functions info.
+* If that was successful, complete the function's info.
*/
function->fn_nargs = procStruct->pronargs;
for (i = 0; i < function->fn_nargs; i++)
@@ -616,12 +619,22 @@
function->datums[i] = plpgsql_Datums[i];
function->action = plpgsql_yylval.program;
+ /*
+* Perform whatever additional compile-time checks we can. Note
+* that we only do this when validating the function; this is so
+* that (a) we don't bother the user with warnings when the
+* function is invoked (b) we don't take the performance hit of
+* doing the analysis more than once per function definition.
+*/
+ if (forValidator)
+ check_function(function);
+
/* Debug dump for completed functions */
if (plpgsql_DumpExecTree)
plpgsql_dumptree(function);
/*
-* add it to the hash table
+* Add it to the hash table
*/
plpgsql_HashTableInsert(function, hashkey);
@@ -664,8 +677,149 @@
plpgsql_error_funcname,
plpgsql_error_lineno);
}
+/*
+ * Emit a warning that the statement 'unreach' is unreachable, due to
+ * the effect of the preceding statement 'cause'.
+ */
+static void
+report_unreachable_stmt(PLpgSQL_stmt *unreach, PLpgSQL_stmt *cause)
+{
+ /*
+* XXX: adjust the line number that is emitted along with the
+* warning message. This is a kludge.
+*/
+ int old_lineno = plpgsql_error_lineno;
+ plpgsql_error_lineno = unreach->lineno;
+ elog(WARNING, "%s is unreachable, due to %s near line %d",
+plpgsql_stmt_typename(unreach),
+plpgsql_stmt_typename(cause),
+cause->lineno);
+
+ plpgsql_error_lineno = old_lineno;
+}
+
/*
+ * Given a list of PL/PgSQL statements, perform some compile-time
+ * checks on them.
+ *
+ * Note that we return as
[BUGS] bug in information_schema?
Found this in 7.4.5, verified it's still in 8.0b4: test=> select * from information_schema.referential_constraints; test|public|$1|test|public|reftest1_pkey|NONE|NO ACTION|CASCADE test|public|$1|test|public|reftest1_pkey|NONE|NO ACTION|NO ACTION test|public|$1|test|public|reftest1_pkey|NONE|NO ACTION|NO ACTION In that case there are three tables all referencing the same column of a fourth - but there is no way at all to tell which row corresponds to which table, and hence no way to join against, say, table_constraints. A similar issue may exist with the check_constraints view, which was the only other place I found where constraint_name is used without any table name being present. I don't know what the spec says, but it seems that something is assuming that constraint_name is unique within the schema, which of course is not the case in the above example. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] bug in information_schema?
On Sat, 27 Nov 2004 14:24:40 +, Andrew - Supernews wrote: > A similar issue may exist with the check_constraints view, which was the > only other place I found where constraint_name is used without any table > name being present. I don't know what the spec says, but it seems that > something is assuming that constraint_name is unique within the schema, > which of course is not the case in the above example. It has been discussed elsewhere some months ago: http://thread.gmane.org/gmane.comp.db.postgresql.sql/11397 The problem makes the INFORMATION_SCHEMA rather useless for some kinds of queries, like you have shown. However, I don't believe that schema-unique constraint names will be an option any time soon, due to backwards compatibility :-( -- Greetings from Troels Arvin, Copenhagen, Denmark ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] Troubles with windows instaler of PostgreSql 8 beta 5
Hi all. Your windows installer of PostgreSQL 8.0.0 Beta 5 (postgresql-8.0.0-beta5-en.msi) is probably corupted. Nothing's happend, when I try execute it. When I open it by WinRar, there are unreadable symbols instead some file and folder names. I have try older versions (beta 4) too with the same effect. Thank you for your time. Ales PROCHAZKA * * ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] Postmaster fails for postgresql-8.0.0-beta5 on Windows 2000 sp4
Hello: Sorry for my english, i am install the 8.0 beta5 version for Windows, all ok, but when igniting the equipment for the second time, it appears to me the legend: "could not receive server response to SSL negotiation pocket" nevertheless postmaster this running. excuse by the annoyances, kindly, Fernando Aguada
[BUGS] WinXP bug
Hi, I downloaded pgSQL 8.0 beta 5 just yesterday. After installing the service did't start so I tried to run it manually and I recieved message that the service was started and had been instantly stopped because of inactivity. I was also experiencing some more difficulties while I was trying to instal it on FAT32 partition. So if you need some more information just let me know. -- Honza Rames ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] plpgsql unreachable code (was BUG #1329: Bug in IF-ELSEIF-ELSE construct)
Neil Conway <[EMAIL PROTECTED]> writes: >> (BTW, another thing this example exposes is that we don't issue warnings >> about trivially-dead-code, such as statements in a basic block that >> follow a RETURN. This would probably be also worth doing.) > Attached is a patch that implements this. Specifically, if there are any > statements in the same block that follow a RETURN, EXIT (without > condition) or RAISE EXCEPTION statement, we issue a warning at CREATE > FUNCTION time: I think it would be sufficient to warn about the statement immediately following the RETURN, EXIT, etc. The way you've got it could easily bury the user in a mass of warning messages that don't really convey any extra information. You could possibly give two alternative messages: WARNING: assignment is unreachable, due to exit near line 6 WARNING: assignment and following statement(s) are unreachable, due to exit near line 6 but I'm not sure that's worth the trouble. Also, you must use ereport not elog for any user-facing error messages, because elog messages aren't candidates for translation. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] BUG #1329: Bug in IF-ELSEIF-ELSE construct
Neil Conway <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> There is no ELSEIF construct. > Sure, but it would be nice to throw a syntax error rather than silently > accepting the function. Unfortunately the way PL/PgSQL's parser works > doesn't make this very easy. Actually, the simplest solution would be to just *allow* ELSEIF as a variant spelling of ELSIF. I cannot see any real good argument for not doing that, and considering that we've seen two people make the same mistake in the past month, my interest in doing it is increasing. > (BTW, I think that fixing how we do parsing > would be one of the prime motivations for rewriting PL/PgSQL. Yeah, if we could think of a way. Copying the main grammar a la ecpg is definitely not the way :-( > Alternatively, we could arrange to have the PL/PgSQL parser pass a block > of text it has identified as a possible SQL statement to the main SQL > parser; if it produces a syntax error, we can pass that syntax error > back to the user. I'm not sure if this would have any negative > ramifications, though. This seems like the most appropriate answer to me; I was thinking of doing that earlier when Fabien and I were fooling with plpgsql error reporting, but didn't get around to it. As long as you only do this in check_function_bodies mode it seems safe enough. One possible problem (if it's done towards the end of parsing as you've suggested for dead-code checking) is that a syntax error in a SQL statement might confuse the plpgsql parser into misparsing statement boundaries, which could lead to a plpgsql parse error much further down, such as a "missing END" at the end of the function. The error would be more useful if reported immediately after the putative SQL statement is parsed. Not sure if that's hard or not. (The same remark applies to dead code checking, now that I think about it.) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] bug in information_schema?
Troels Arvin <[EMAIL PROTECTED]> writes: > On Sat, 27 Nov 2004 14:24:40 +, Andrew - Supernews wrote: >> something is assuming that constraint_name is unique within the schema, >> which of course is not the case in the above example. > The problem makes the INFORMATION_SCHEMA rather useless for some kinds of > queries, like you have shown. However, I don't believe that schema-unique > constraint names will be an option any time soon, due to backwards > compatibility :-( We have changed 8.0 to ensure that automatically-generated constraint names are unique across a schema. I doubt we will ever enforce that against user-specified names, though. If you want to use the information schema to trace constraints, you'll have to impose that discipline on yourself. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
