[BUGS] Error on reference to inherited primary key
Creating tables this way: A has a primary key B inherits A C references B results in an error message on the CREATE TABLE for C (ERROR: PRIMARY KEY for referenced table "b" not found). To reproduce: create table A ( id integer primary key ); create table B ( dummy integer ) inherits (A); create table C ( ref integer references B ); psql:repro.sql:14: ERROR: PRIMARY KEY for referenced table "b" not found AFAIK the SQL code is correct. B should inherit the primary key from A, so C should be able to reference B. The workaround appears to be explicitly naming the primary key column: create table C ( ref integer references B(id) ); I'm using PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc 2.96. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] Homepage images do not set ALT attribute
Christian Reis ([EMAIL PROTECTED]) reports a bug with a severity of 3 The lower the number the more severe it is. Short Description Homepage images do not set ALT attribute Long Description Well, the PostgreSQL.org homepage has a very pretty logo table at the top, which lays out very nicely in graphical browsers. However, most (if not all of) the images that compose the logo do not have the ALT attribute set, making it less usable for text-browsers and page readers for the visually challenged. A nice way to check is to browse using a text browser such as lynx. Sample Code No file was uploaded with this report ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] can't compile JDBC1
joachim wolf ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description can't compile JDBC1 Long Description in postgresql 7.1, compiling of JDBC1 isn't possible, syntax errors in the java source (JDBC2 works): make[3]: Entering directory `/usr/src/postgresql-7.1/src/interfaces/jdbc' /opt/java/ant/bin/ant -buildfile ../../../build.xml -Dmajor=7 -Dminor=1 -Dfullversion=7.1 -Ddef_pgport=5432 Buildfile: ../../../build.xml jar: call: prepare: [mkdir] Created dir: /usr/src/postgresql-7.1/src/interfaces/jdbc/build [mkdir] Created dir: /usr/src/postgresql-7.1/src/interfaces/jdbc/jars check_versions: driver: [copy] Copying 1 files to /usr/src/postgresql-7.1/src/interfaces/jdbc/org/postgresql Configured build for the JDBC1 edition driver. compile: [javac] Compiling 37 source files to /usr/src/postgresql-7.1/src/interfaces/jdbc/build [javac] /usr/src/postgresql-7.1/src/interfaces/jdbc/org/postgresql/jdbc1/Statement.java:291: Missing term. [javac] if (result != null) && ((org.postgresql.ResultSet)result.reallyResultSet()) [javac] ^ [javac] /usr/src/postgresql-7.1/src/interfaces/jdbc/org/postgresql/jdbc1/Statement.java:291: Invalid expression statement. [javac] if (result != null) && ((org.postgresql.ResultSet)result.reallyResultSet()) [javac] ^ [javac] /usr/src/postgresql-7.1/src/interfaces/jdbc/org/postgresql/jdbc1/Statement.java:291: ';' expected. [javac] if (result != null) && ((org.postgresql.ResultSet)result.reallyResultSet()) [javac] ^ [javac] 3 errors BUILD FAILED /usr/src/postgresql-7.1/src/interfaces/jdbc/build.xml:99: Compile failed, messages should have been provided. Sample Code No file was uploaded with this report ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Error on reference to inherited primary key
On Fri, 13 Apr 2001 [EMAIL PROTECTED] wrote: > Creating tables this way: > >A has a primary key >B inherits A >C references B > > results in an error message on the CREATE TABLE for C (ERROR: PRIMARY KEY for >referenced table "b" not found). > > To reproduce: > > create table A > ( > id integer primary key > ); > > create table B > ( > dummy integer > ) inherits (A); > > create table C > ( > ref integer references B > ); > > psql:repro.sql:14: ERROR: PRIMARY KEY for referenced table "b" not found > > AFAIK the SQL code is correct. B should inherit the primary key from A, so C should >be able to reference B. Primary keys/Unique constraints do not currently inherit (they should, but there are some questions about how they should). If you want id to have the properties of a primary key on B, you need to make a unique constraint on B, I believe the NOT NULL is already inherited. > The workaround appears to be explicitly naming the primary key column: > create table C > ( > ref integer references B(id) > ); This will not work for 7.1 since it checks for unique constraints (see above) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] Bug in send()
Hi i'm developing a searchengine which uses PostgreSQL (duh:) I've fond erronuos behavour when I send a SIGTERM to my application when then query is in progress.. The send() loop will go out of control in an endless loop and that is clearly wrong. I'm not going into the source unless you say that's a good idea and send you some working code but you probably have a better oversight into the code and can make some more logical code then I can... This is the log; FATAL: pq_endmessage failed errno=32 pq_flush: send() failed broken pipe This is IHMO an example of trying to do it right but forgetting how dumb users are. You obviously catch the SIGPIPE but then gerget to check the errno. It's a quick fix no doubt. Load goed to 100% btw. In anycase let me know what happens, Cheers, Dennis Fleurbaaij [EMAIL PROTECTED]
[BUGS] me bad :)
Oops :) We're talking 7.1 rc4 here. -- Met vriendelijke groet, Dennis Fleurbaaij <[EMAIL PROTECTED]> Stichting CORE http://www.core-lan.nl Tel: +31 (0)6 54 21 53 65 Fax: +31 (0)20 86 47 059
Re: [BUGS] Bug in send()
Dennis Fleurbaaij <[EMAIL PROTECTED]> writes: > FATAL: pq_endmessage failed errno=32 > pq_flush: send() failed broken pipe As near as I can tell, this is the trace of a backend exiting after the client program ungracefully quit. If you want to argue that this is a Postgres bug then you will need to provide considerably more evidence. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] g++ not working for postgresql extension languages?
Hello,
Here is something very important that I think might be a bug for you to look
into as there is some aparent inconsistancies
I was doing some testing before I started to write my c++ routine to extend
PostgreSQL 7.03 on my Linux box and found this problem.
I made two copies of the same file called "funcs.c" and "funcs.cc" as can be
see below.
If I work with the "funcs.cc" file then I can get:
-
[root@Treazurac /test]# g++ -I./include -I./backend -O2 -Wall
-Wmissing-prototypes -Wmissing-declarations -I/usr/include/pgsql -I/usr/include
-fpic -c -o funcs.o funcs.cc
[root@Treazurac /test]# g++ -shared -o funcs.so funcs.o
[root@Treazurac /test]# ls
Makefile Makefile.global Makefile.port funcs.cc funcs.o funcs.so*
funcs.sql
[root@Treazurac /test]# pico -w funcs.sql
[root@Treazurac /test]# psql -f funcs.sql -d trdata
DROP
CREATE
[root@Treazurac /test]# psql trdata
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
trdata=# select concat_text('a','b');
ERROR: Can't find function concat_text in file /test/funcs.so
trdata=#
--
And although I should not be running as "root", this is a test machine and it
is ok for the time being.
If I do the same thing as above, but using the "funcs.c" file (which is the
exact same file just renamed)
---
funcs.c and funcs.cc
-
#include "postgres.h" // for variable length type
#include #include #include #include
#include // for unix crypt function
text *
concat_text(text *arg1, text *arg2);
text *
concat_text(text *arg1, text *arg2)
{
int32 new_text_size = VARSIZE(arg1) + VARSIZE(arg2) - VARHDRSZ;
text *new_text = (text *) malloc(new_text_size);
memset((void *) new_text, 0, new_text_size);
VARSIZE(new_text) = new_text_size;
strncpy(VARDATA(new_text), VARDATA(arg1), VARSIZE(arg1)-VARHDRSZ);
strncat(VARDATA(new_text), VARDATA(arg2), VARSIZE(arg2)-VARHDRSZ);
return (new_text);
}
--
with funcs.sql
--
DROP FUNCTION concat_text(text, text);
CREATE FUNCTION concat_text(text, text) RETURNS text
AS '/test/funcs.so' LANGUAGE 'c';
With the "funcs.c" file in place I get:
-
[root@Treazurac /test]# gcc -I./include -I./backend -O2 -Wall
-Wmissing-prototypes -Wmissing-declarations -I/usr/include/pgsql -I/usr/include
-fpic -c -o funcs.o funcs.c
[root@Treazurac /test]# gcc -shared -o funcs.so funcs.o
[root@Treazurac /test]# psql -f funcs.sql -d trdata
DROP
CREATE
[root@Treazurac /test]# psql trdata
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
trdata=# select concat_text('a','b');
concat_text
-
ab
(1 row)
trdata=#
-
so now I do not understand why the "gcc" version works and the "g++" version
does not?
Just a side note in that I can easliy compile c++ the examples in the
interfaces/libpq++ directory without any problems so that this is very strange
to me.
I really need the "g++" version to work correctly as well?
Any ideas on how to fix this so that I can use c++ functions compiled with g++
in the PL/pgSQL extensions?
Cheers
Lonnie
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[BUGS] Re: g++ not working for postgresql extension languages?
> Any ideas on how to fix this so that I can use c++ functions compiled with g++
> in the PL/pgSQL extensions?
To implement function overloading, g++ (and other c++ compilers) use
"name mangling" to allow functions and methods with the same name but
with different arguments to be handled by standard linkers. It is a
clever scheme, but it does require that you explicitly identify
functions or methods written in C++ which you will be calling from C or
from other non-C++ languages.
You will want to do this anyway (even if you could instead figure out
what the mangled name looks like and declare that as the entry point)
because C++ has features and conventions to implement, for example,
exceptions which are incompatible with the calling C code.
You make them compatible by surrounding the declaration of your C++
function with the following:
extern "C" {
}
The actual implementation does not have to have this, only your
prototype declaration. The function or method name will no longer be
mangled, but of course you can not overload it either.
Good luck!
- Thomas
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
