[BUGS] BUG #5464: ecpg on 64bit system converts "long long" to "long"
The following bug has been logged online:
Bug reference: 5464
Logged by: Michael Enke
Email address: michael.e...@wincor-nixdorf.com
PostgreSQL version: 8.4.4
Operating system: Linux
Description:ecpg on 64bit system converts "long long" to "long"
Details:
This applies for at least ecpg 4.5.0 and 4.4.0.
On 32 bit system the type is not changed.
Example:
EXEC SQL INCLUDE sqlca;
EXEC SQL BEGIN DECLARE SECTION;
long long test;
EXEC SQL END DECLARE SECTION;
int main(int argc, char **argv) {
return 0;
}
If you run it through ecpg, in the resulting c file
the variable test has type long on 64 bit system.
On 32 bit system it is long long.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5464: ecpg on 64bit system converts "long long" to "long"
Michael Meskes schrieb: > On Wed, May 19, 2010 at 10:34:42AM -0700, John R Pierce wrote: >> I'm pretty sure it varies with the 64 bit system. I believe on IBM >> Power, LONG LONG *is* 64 bit. > > I'm currently without real access to a 64bit system until I come back home. If > it is 64bit on *all* 64bit systems the problem is slightly different. > > Michael The size of long *and* long long is 64 bit on x86_64 system. But the compiler throws warnings for %lld with long int type. It should not be required to change the code to not run into such warnings. Yes, I know the PRI... macros from inttypes.h ... Michael WINCOR NIXDORF International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193 Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #2550: pg_dumpall 7.4.13 -> restore 8.1.4 problem
The following bug has been logged online: Bug reference: 2550 Logged by: Michael Enke Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.4 Operating system: SuSE Linux 9.2 Description:pg_dumpall 7.4.13 -> restore 8.1.4 problem Details: I used pg_dumpall in 7.4.13. In the created backup there is a ... delete from pg_shadow ... since it is a table, all ok. But in 8.1.4 it is a view so I get an error at restore: ERROR: cannot delete from a view HINT: You need an unconditional ON DELETE DO INSTEAD rule. The same for pg_group Is there a way to patch the output of pg_dumpall 7.4? I found nothing in the docu (heavy to look for, pg_dumpall found in so many places). ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #2574: C function: arg TEXT data corrupt
The following bug has been logged online:
Bug reference: 2574
Logged by: Michael Enke
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: Open Suse 10.1 and CentOS 4.3
Description:C function: arg TEXT data corrupt
Details:
I created a C function:
extern Datum test_arg(PG_FUNCTION_ARGS);
PG_FUNCTION_INFO_V1(test_arg);
Datum test_arg(PG_FUNCTION_ARGS) {
elog(INFO, "arg: %s", VARDATA(PG_GETARG_TEXT_P(0)));
PG_RETURN_INT16(0);
}
and used the
CREATE FUNCTION test_arg(TEXT) RETURNS INT4 AS 'path_to_lib.so' LANGUAGE
'C';
If I call this function "the first time"
after connecting with psql, the info output shows
corrupted data, the second and further call is ok:
[EMAIL PROTECTED]:~/uwx9/SVN/tpl/trunk/db/postgresql/src> psql -U tplinux
Welcome to psql 8.1.3, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
tplinux=> select test_arg('1');
INFO: arg: [EMAIL PROTECTED]
test_arg
--
0
(1 row)
tplinux=> select test_arg('1');
INFO: arg: 1
test_arg
--
0
(1 row)
The same problem is with input length of 2, 3, 4, 8 char (and may be more).
With input of 4 char I never get correct value.
No problem for first call with 5, 6 , 7 char,
but with 5 char problem if before called with 6 char.
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[BUGS] BUG #3659: should use implizit type cast in check constraint
The following bug has been logged online:
Bug reference: 3659
Logged by: Michael Enke
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: Linux, CentOS5
Description:should use implizit type cast in check constraint
Details:
Hello,
if I have defined my own data type/operators,
in a check constraint this type is used
instead of ::text.
Shouln't be there an implizit typecast to ::text?
Otherwise I always have to add an explicit typecast
if I have conflicting types/operators
but this would not be nice.
create table b(a varchar(1) check(a in ('1','2')));
\d b:
Table "public.b"
Column | Type | Modifiers
+--+---
a | character varying(1) |
Check constraints:
"b_a_check" CHECK (a = '1'::text OR a = '2'::text)
But if I have defined a type testchar and create this table again without an
explicit type cast:
\d b
Table "public.b"
Column | Type | Modifiers
+--+---
a | character varying(1) |
Check constraints:
"b_a_check" CHECK (a = '1'::testchar OR a = '2'::testchar)
I can send test case files if required.
Regards,
Michael
---(end of broadcast)---
TIP 1: 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] BUG #4056: docu wrong for sqlerrmc[70]
The following bug has been logged online: Bug reference: 4056 Logged by: Michael Enke Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: Linux CentOS 5.1 Description:docu wrong for sqlerrmc[70] Details: In the 8.3.1 documentation, "32.11.2. sqlca" is written: char sqlerrmc[70]; But a sizeof(sqlca.sqlerrm.sqlerrmc) tells me: 150 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #2012: SPI_fnumber sigsegv when compiled with 7.4.8
The following bug has been logged online: Bug reference: 2012 Logged by: Michael Enke Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: Linux SuSE 10 Description:SPI_fnumber sigsegv when compiled with 7.4.8 Details: A 'C' function, which uses the SPI_fnumber, which was compiled on 7.4.8 crashes the 8.0.3 server with a SIGSEGV. The same source code, compiled on 8.0.3 makes no trouble. ---(end of broadcast)--- TIP 1: 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] BUG #7908: documentation mismatch
The following bug has been logged on the website: Bug reference: 7908 Logged by: Michael Enke Email address: michael.e...@wincor-nixdorf.com PostgreSQL version: 9.1.8 Operating system: CentOS 6.2 Description: in page docs/9.1/static/trigger-definition.html (applies also for other versions): ... while row-level AFTER triggers fire at the end of the statement ... should be changed to ... while row-level AFTER triggers fire immediately after a particular row is operated on ... -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7908: documentation mismatch
Ups, thank you for clarification. Regards, Michael Am 27.02.2013 16:45, schrieb Tom Lane: > michael.e...@wincor-nixdorf.com writes: > >> in page docs/9.1/static/trigger-definition.html (applies also for other >> versions): >> ... while row-level AFTER triggers fire at the end of the statement ... >> should be changed to >> ... while row-level AFTER triggers fire immediately after a particular row >> is operated on ... >> > Uh, no, that text is correct as written. > > regards, tom lane > WINCOR NIXDORF International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Geschäftsführer: Eckard Heidloff (Vorsitzender), Dr. Jürgen Wunram (stellv. Vors.), Jens Bohlen Vorsitzender des Aufsichtsrats: Dr. Alexander Dibelius Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193 Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8307: can reproduce: pg_dump: schema with OID xxxxxx does not exist
The following bug has been logged on the website: Bug reference: 8307 Logged by: Michael Enke Email address: michael.e...@wincor-nixdorf.com PostgreSQL version: 9.1.8 Operating system: Linux/CentOS 6.2 Description: Hi, after hitting the above error and found that this is a long lasting one which nobody knows how to reproduce, I found a way to reproduce it: In one session create tables in a schema, in another session drop that schema. Here comes my test script: #!/bin/sh DB=testdb # change if you need NUM=2000 # adjust so that creation takes enough time to issue drop schema CREATE=/tmp/$DB.sql START=/tmp/testdb.start END=/tmp/testdb.end LANG=C rm -f $START $END >$CREATE for I in $(seq $NUM); do echo "create table t$I(at text, bt text, ct text, dt text);" >> $CREATE echo "create table tt$I as select g1.*, t$I.* from g1, t$I where 1=2;" >> $CREATE echo "drop table t$I;" >> $CREATE done ( psql -U postgres -d template1 < testdb.dump )& while [ ! -f $START ]; do usleep 10; done sleep 1 psql -U postgres -d $DB -c "drop schema testschema cascade" 2>&1 | grep "^NOTICE" if [ -f $END ]; then echo "too late" fi wait rm -f $START $END # end script There are 3 possible errors reported (I executed 10x): 1: Deadlock detected: 1x 2: Could not open relation for Create: 4x 3: cache lookup failed: 5x In case of 2 or 3 pg_dump reports above error. If I modify the creation to only one line: echo "create table tt$I as select g1.* from g1 where 1=2;" >> $CREATE then in 100% I get the case number 2. Hope it helps tracking down the reason. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: BUG #8307: can reproduce: pg_dump: schema with OID xxxxxx does not exist
The script does not work as expected in the very first case where testdb does not exist. Please change the "\set ON_ERROR_STOP" to appear behind the "drop database $DB;" WINCOR NIXDORF International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Geschäftsführer: Eckard Heidloff (Vorsitzender), Dr. Jürgen Wunram (stellv. Vors.), Jens Bohlen, Olaf Heyden Vorsitzender des Aufsichtsrats: Dr. Alexander Dibelius Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193 Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
