[BUGS] pg_dump does not reflect changes in column names with primary keys
Edward Pilipczuk ([EMAIL PROTECTED]) reports a bug with a severity of 3 The lower the number the more severe it is. Short Description pg_dump does not reflect changes in column names with primary keys Long Description If a table with primary key is created (CREATE TABLE), that implicitly forces also creating an index table, and after creation the name of that column is renamed (ALTER TABLE), the we get problem with indexing. The index table still behaves in "old fashion", i.e., it reflects the original primary key. It influences also pg_dump bahaviour. The error is reported when restoring data base dumped previously by pg_dump utility. The workaround I've found here is to edit manually dump file in order to correct the name of the index table. Then restoring works fine. Sample Code No file was uploaded with this report
[BUGS] Access 97 and PSQL ODBC
Charles ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description Access 97 and PSQL ODBC Long Description As of now this is not reproducible. Sometimes when entering data into a PSQL table through Microsoft Access, when you leave the field to commit the record to the table it changes all of the data you entered to #Deleted. If you close the table and open it again the data you entered is back. The data must be getting into the table but it is annoying the the only way to see the data you entered is to close the table and reopen it. Any suggestions would be greatly appreciated. Thanks Sample Code No file was uploaded with this report
[BUGS] Access 97 and PSQL ODBC Update
Charles ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description Access 97 and PSQL ODBC Update Long Description Update: I can reproduce this now. In a text field if a record already has the text "Hello" in it and I type that same text in to the new field, it gives this error. I checked and Access does not think there is an index on this field. There is only one index and that is a unique index on an autonumber field. As of now this is not reproducible. Sometimes when entering data into a PSQL table through Microsoft Access, when you leave the field to commit the record to the table it changes all of the data you entered to #Deleted. If you close the table and open it again the data you entered is back. The data must be getting into the table but it is annoying the the only way to see the data you entered is to close the table and reopen it. Any suggestions would be greatly appreciated. Thanks Sample Code No file was uploaded with this report
[BUGS] bugs
POSTGRESQL BUG REPORT TEMPLATE
Your name : Alexei E. Korneyev
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture : Intel Pentium II
Operating System : Linux RedHat 2.2.12
PostgreSQL version : PostgreSQL-7.0.2
Compiler used : uncnown Build Host: utility.wgcr.org
Please enter a FULL description of your problem:
i create this:
create table "users" (
namevarchar(10) PRIMARY KEY
);
create table "stat" (
peernamevarchar(10) REFERENCES users(name)
);
revoke ALL on stat,users from PUBLIC;
grant INSERT, SELECT on stat to statist;
grant select on users to statist;
grant ALL on stat to basemaster;
insert into users values('niva');
insert into stat values ('niva',abstime('now'),timespan(0),8607272,1829436);
-
After that I do(make) connection as the user statis and execute cmd:
---
insert into stat
values('niva',abstime('now'),timespan(abstime('now')-(select max(timewrite)
from stat)),50,50);";
--
server say:Access deny on users...
After I change the rights on:
grant select,update on users to statist;
,the query exec successfully
Alexei E. Korneyev
[EMAIL PROTECTED]
Re: [BUGS] PG still fussy to compile on Solaris + GCC, may stillneed Sun ld
Okay, thanks for the help. Matt Matt Benjamin President/CTO The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 tel. 734-761-4689 fax. 734-769-8938 pgr. 734-431-0118 On Sat, 2 Sep 2000, Tom Lane wrote: > Matt Benjamin <[EMAIL PROTECTED]> writes: > > What do you mean, "do what it wanted?" The configure script produced a > > setup that would not build a perl interface, and the error was related to > > SunWS compiler options. > > > Sounds like half my problem was using the Perl5 that Sun provides with > > Solaris 8. . . > > Urgh, could be. If you'd built and installed Perl yourself, it'd be a > pretty good bet that it'd report a compiler name and switches that would > actually work on your box. If you're using a vendor-supplied Perl then > I could see how there might be a problem: perhaps they used a compiler > different from the one you have. > > Not sure what we could/should do about this. We used to try to force > the perl5 interface to be built with the same compiler/switches used for > Postgres. Our current behavior (ie, just accepting MakeMaker's stored > recollection of the Perl build setup) was chosen after getting reports > that that didn't work either, on machines where there was actually some > material difference. Seems like we lose either way, just on different > machines... > > > The larger problem was of linking the PG libs. I had a copy of Sun ld > > around, but, since this (somehow, like the compiler) doesn't come with the > > OS, it is a safe bet that a fair number of folks won't have it. > > I'd argue that that means GNU ld is broken on your platform, and you > ought to be complaining to the bintools people about it. Postgres > doesn't do anything particularly out-of-the-ordinary as far as the > linker is concerned. > > regards, tom lane >
[BUGS] Handling from UPDATE, SELECT, ... with now rows affected
Hello PostgreSQL-Team,
sorry that i'm not using the standard bug report, but I think i have not a bug.
I'm using the unixODBC with PostgreSQL and I have a little problems discussed
with nick the
maintainer from unixODBC. And for now we are stuck. So what is the problem. I
hope i can get it
on the point.
Looking in the PostgreSQL C-API to the ExecStatusType there is no Retcode for
"I process the command or query but not a single row is returned or touched"
for long: for example using an UPDATE-Statment that does not touch any row, I
does not
get this info. Sure i can get before an UPDATE count(*) but this is ugly
and wrong. The same
is for an SELECT-Statment, I can handle this with looking in the RowCount, but
I get a problem using
SELECT MIN(...) (look at the end).
So now the question/suggestion: Is it possible to get the backend get the
information back to the client
if a row is touched/queried in the ExecStatusType for Example:
PGRES_COMMAND_OK_WITH_ROW_TOUCHED,
PGRES_TUPLES_EMPTY ?
Hope to hear from you
Rainer
*An: nick
Verteiler:
Papierkopie:
Von: Rainer Schiele
BTB/Tel: SYTKIV / 0721/4004-1843
Datum: 01.09.2000 12.58.36
*Thema: unixODBC - SQLFetch RC
Hello Nick,
i think i have discovered a mismatch in the Handling of SQLFetch. We have had a
similary Problem (but not the same, I put it on the end: Problem1).
OK, let's start:
Linux 2.2.14, PostgreSQL 7.0.2, unixODBC-1.8.12
For example when I use and SQL-Statement like
SELECT Number FROM TEDAV003 WHERE id = 1000
and the Row with id = 1000 does not exists i get an SQL_NO_DATA_FOUND from
SQLFetch.
This seems OK.
But using the statment:
SELECT MIN(Number) FROM TEDAV003 WHERE id = 1000
SQLFetch return SQL_SUCCESS (Wrong) and the Binded Cols where not been touched
(Right)
I think the problem is using the Row Count from the Select-Results which is 1,
but this does not mean we found data !!!
Rainer
PS: Had you time to look in my Threading-Problem. I have get a deep breath and
going in your code
(..\Drivers\ProstgreSQL\statement.c line 770) where you decide to start a
transaction or not. And I did
not seen a synchronization there. Will that be synchronized in the upper layers
?
Problem 1
I have a problem with SQL-Updates and the Retcode from SQLExecDirect.
I think i make something wrong because the problem is so trivial that this can
not be a bug!
Let's start:
I have a very simple Routine that makes an update in the Database:
int DBProduktForTargInsert(DBHandle*dbHandle,
short prodNr,
int targNr,
int jobNr,
char*userId,
DBErrInfo *errInfo) {
SQLCHARstmt[MAXSTMTLENGTH];
SQLRETURN sqlrc;
sprintf(stmt, StmtProduktForTargInsert1,
prodNr, targNr, jobNr, userId,
prodNr, targNr);
sqlrc = SQLExecDirect(dbHandle->hstmt, stmt, SQL_NTS);
fprintf(stderr, "sqlrc: %d\n", sqlrc);
if (sqlrc != SQL_SUCCESS) {
DBFillErrInfo(dbHandle, errInfo);
return sqlrc;
}
return sqlrc;
}
The SQL-Statement that is going to the Database is:
UPDATE TESVK005
SET prod_nr = 1,
targ_nr = 2,
job_nr = 3,
upd_uid = 'UserID',
upd_date = CURRENT_DATE,
upd_time = CURRENT_TIME
WHERE prod_nr = 1 AND targ_nr = 2
Seems quite right!
In the table there are no entries !! This is OK!
BUT the sqlrc is SQL_SUCCESS (0) not SQL_NO_DATA_FOUND (100).
My Dokumentation (IBM DB2/2) says for a Searched Update with no rows satisfy
the serach condition SQL_NO_DATA_FOUND must be returned!!
[BUGS] Possible bug in referential integrity system
The submit button on the form located at http://www.postgresql.org/bugs/bugs.php?1 results in a report of a parsing error, so I'm sending this here as the alternative. Is the following a bug in the referential integrity system? This is for PG 7.0.0. I realize that declaring the "ref" column in t2 additionally as "not null" would prevent this. However, why does the "references" check allow insertion of a null value into t2 when there are no corresponding null value in the num column of t1? If this is actually fixed in 7.0.2, then please accept my apologies. === => create table t1 (num int4, name text); CREATE => create table t2 (ref int4 references t1 (num), val text); NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s) CREATE => insert into t1 values (1, 'Widget1'); INSERT 17518650 1 => insert into t2 values ( (select num from t1 where name = 'Widget1'), 'Valuable'); INSERT 17518651 1 => insert into t2 values ( (select num from t1 where name = 'widget2'), 'Bug?'); INSERT 17518652 1 => select * from t2; ref | val -+-- 1 | Valuable | Bug? (2 rows) => select * from t2 where ref is null; ref | val -+-- | Bug? (1 row) -- Microsoft is not the answer.Boycott Microsoft Home page Microsoft is the question. http://www0.vcnet.com/bms No is the answer. Microsoft: Bringing you ten-year old technology, tomorrow, maybe.
Re: [BUGS] PG still fussy to compile on Solaris + GCC, may stillneed Sun ld
Hi Tom, What do you mean, "do what it wanted?" The configure script produced a setup that would not build a perl interface, and the error was related to SunWS compiler options. The larger problem was of linking the PG libs. I had a copy of Sun ld around, but, since this (somehow, like the compiler) doesn't come with the OS, it is a safe bet that a fair number of folks won't have it. Sounds like half my problem was using the Perl5 that Sun provides with Solaris 8. . . Matt Matt Benjamin President/CTO The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 tel. 734-761-4689 fax. 734-769-8938 pgr. 734-431-0118 On Sat, 2 Sep 2000, Tom Lane wrote: > [EMAIL PROTECTED] writes: > > 2. PG Perl interface Makefile.PL produced Sun compiler options for > > compiling PG.c, e.g., "-KPIC", etc. > > We deliberately try to build the Perl interface with the same compiler > and options that the local Perl installation claims it was built with, > regardless of what you are building Postgres with. Experience so far > on multi-compiler platforms is that it's much more likely that the > interface will actually work if built that way (remember it's going to > link into the Perl executable, not into Postgres). > > Did it not work if you just let the makefile do what it wanted? > > regards, tom lane >
[BUGS] Problem
Hello In the final part of this message you found the help message of the actual pg_dump edition. There is no option to choose "insert proper sql strings" and there is no point on which I can choose a file the program can put in the output. What can I do to put it in later postgress editions ? thanks Ralf --- Usage: pg_dump [options] dbname Options: -a, --data-only dump out only the data, not the schema -c, --clean clean (drop) schema prior to create -d, --insertsdump data as INSERT, rather than COPY, commands -D, --attribute-inserts dump data as INSERT commands with attribute names -h, --host server host name -i, --ignore-version proceed when database version != pg_dump version -n, --no-quotes suppress most quotes around identifiers -N, --quotes enable most quotes around identifiers -o, --oids dump object ids (oids) -p, --port server port number -s, --schema-onlydump out only the schema, no data -t, --table dump for this table only -u, --password use password authentication -v, --verboseverbose -x, --no-acl do not dump ACL's (grant/revoke) If no database name is not supplied, then the PGDATABASE environment variable value is used. Report bugs to <[EMAIL PROTECTED]>. postgres@linux:~ > -- Bis dann Ralf FAX NUMMER : 069-79123-8384 Handy : 0174-6432399 Harley Davidson history page (ger) : http://www.chopper.de _ In the day we sweat it out in the streets of a runaway american dream At night we ride through mansions of glory in suicide machines [Bruce Springsteen : Born to run]
[BUGS] RE: [BUG] calling lo_creat()
This is not a bug. The problem was that I was not calling lo_unlink() after consecutive lo_creat(), lo_close() calls. I found this out by looking at the file system containing the database and seeing hundreds of xinvOID and xinxOID files. After cleaning up these files I was able to run this program without error. > -Original Message- > From: Barnes, Sandy (Sandra) > Sent: Tuesday, August 29, 2000 11:06 AM > To: '[EMAIL PROTECTED]'; 'Tom Lane' > Cc: Barnes, Sandy (Sandra) > Subject: [BUG] calling lo_creat() > > Per Tom's suggestion I am submitting my problem to BUGS email list. Our > project would like to use PostgreSQL in an embedded application that is > highly reliant on creating, storing and accessing large objects. I had > hoped that when lo_creat() returned a zero, I could test for this and call > lo_creat() until a valid oid is returned. The Database log error tells me > to recreate an index. Why ? How?... not sure what to do from here. > Thank you in advance for the time you may spend on this ! > > Platform: PostgreSQL 7.0.2 on RedHat6.2 Linux > Test: Testing the creation of large objects. I was putting the large > objects into a database table but this >test program recreates the error for me without having to do that. > Program Error: Can't create large objectoid [55592] 21 > Database Log Error: FATAL 1: my bits moved right off the end of the world! > Recreate index > pg_attribute_relid_attnum_index > > > > > << File: testOid2.doc >> > > > << File: output.doc >> > > Sandy Barnes > email[EMAIL PROTECTED] >
[BUGS] /usr/include/pgsql/os.h does not exist
Charles Choi ([EMAIL PROTECTED]) reports a bug with a severity of 1 The lower the number the more severe it is. Short Description /usr/include/pgsql/os.h does not exist Long Description I am trying to install Postgresql 7.0.2 using the RPM on RedHat 6.2. In the example code section I have shown the contents of the directory /usr/include/pgsql I have used the RPM postgresql-devel-7_0_2-2_i386.rpm. I have installed both the version on your site and yet again from the RedHat site. Same problem. Hope you can fix this - thanks! -Charles Sample Code socworks1 /usr/include/pgsql>ls -al total 224 drwxr-xr-x 17 root root 4096 Sep 5 20:13 ./ drwxr-xr-x 44 root root 8192 Sep 5 20:13 ../ drwxr-xr-x2 root root 4096 Sep 5 20:13 access/ -rw-r--r--1 root root19779 Jun 12 14:21 c.h drwxr-xr-x2 root root 4096 Sep 5 20:13 catalog/ drwxr-xr-x2 root root 4096 Sep 5 20:13 commands/ -rw-r--r--1 root root16412 Jun 12 14:21 config.h -r--r--r--1 root root 1261 Jun 12 14:20 ecpgerrno.h -r--r--r--1 root root 1233 Jun 12 14:20 ecpglib.h -r--r--r--1 root root 1856 Jun 12 14:20 ecpgtype.h drwxr-xr-x2 root root 4096 Sep 5 20:13 executor/ -r--r--r--1 root root25046 Jun 12 14:20 fmgr.h drwxr-xr-x2 root root 4096 Sep 5 20:13 iodbc/ drwxr-xr-x2 root root 4096 Sep 5 20:13 lib/ -r--r--r--1 root root 403 Jun 12 14:20 libpgeasy.h -r--r--r--1 root root 650 Jun 12 14:20 libpgtcl.h drwxr-xr-x2 root root 4096 Sep 5 20:13 libpq/ drwxr-xr-x2 root root 4096 Sep 5 20:13 libpq++/ -r--r--r--1 root root 940 Jun 12 14:20 libpq++.h -r--r--r--1 root root12383 Jun 12 14:20 libpq-fe.h -r--r--r--1 root root12378 Jun 12 14:20 libpq-int.h drwxr-xr-x2 root root 4096 Sep 5 20:13 nodes/ lrwxrwxrwx1 root root 25 Sep 5 20:13 os.h -> .././include/port/linux.h drwxr-xr-x2 root root 4096 Sep 5 20:13 parser/ drwxr-xr-x3 root root 4096 Sep 5 20:13 port/ -rw-r--r--1 root root 7268 Jun 12 14:21 postgres.h -rw-r--r--1 root root 1222 Jun 12 14:21 postgres_ext.h -r--r--r--1 root root 5484 Jun 12 14:20 pqexpbuffer.h drwxr-xr-x2 root root 4096 Sep 5 20:13 rewrite/ -r--r--r--1 root root 943 Jun 12 14:20 sql3types.h -r--r--r--1 root root 1020 Jun 12 14:20 sqlca.h drwxr-xr-x2 root root 4096 Sep 5 20:13 storage/ drwxr-xr-x2 root root 4096 Sep 5 20:13 tcop/ drwxr-xr-x2 root root 4096 Sep 5 20:13 utils/ socworks1 /usr/include/pgsql>ls os.h os.h@ socworks1 /usr/include/pgsql>uname -a Linux socworks1 2.2.16-3 #1 Mon Jun 19 18:49:25 EDT 2000 i686 unknown socworks1 /usr/include/pgsql>more os.h os.h: No such file or directory No file was uploaded with this report
Re: [BUGS] Possible bug in referential integrity system
Hello! Keys phrase 'NOT NULL' simple=# create table t1 (num int4 PRIMARY KEY, name text); NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 't1_pkey' for table 't1' CREATE simple=# create table t2 (ref int4 references t1 (num) NOT NULL, val text); NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s) CREATE simple=# insert into t1 values (1, 'Widget1'); INSERT 80324 1 simple=# insert into t2 values ( (select num from t1 where name = 'widget2'), 'Bug?'); ERROR: ExecAppend: Fail to add null value in not null attribute ref > => create table t1 (num int4, name text); > CREATE > => create table t2 (ref int4 references t1 (num), val text); > NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s) > CREATE > > => insert into t1 values (1, 'Widget1'); > INSERT 17518650 1 > > => insert into t2 values ( (select num from t1 where name = 'Widget1'), 'Valuable'); > INSERT 17518651 1 > => insert into t2 values ( (select num from t1 where name = 'widget2'), 'Bug?'); > INSERT 17518652 1 Alexei E. Korneyev [EMAIL PROTECTED]
[BUGS] bug in date_part() function in 6.5.2, 7.0.2
Alex Karpov ([EMAIL PROTECTED]) reports a bug with a severity of 1
The lower the number the more severe it is.
Short Description
bug in date_part() function in 6.5.2, 7.0.2
Long Description
Checked on Postgres version 6.5.2 and 7.0.2:
Incorrect DOW and DAY parts of date calculation. See exanple code.
I`ve not tested this function for another time interval, only for march 2000.
?column? | date_part | date_part
+---+---
24.03.2000 |24 | 5
25.03.2000 |25 | 6
26.03.2000 |25 | 6
27.03.2000 |27 | 1
(4 rows)
Sample Code
create table oops (date date);
insert into oops (date) values (to_date('24.03.2000','dd.mm.'));
insert into oops (date) values (to_date('25.03.2000','dd.mm.'));
insert into oops (date) values (to_date('26.03.2000','dd.mm.'));
insert into oops (date) values (to_date('27.03.2000','dd.mm.'));
select
date::date
,date_part('day',date::date)
,date_part('dow',date::date)
from oops
order by date;
?column? | date_part | date_part
+---+---
24.03.2000 |24 | 5
25.03.2000 |25 | 6
26.03.2000 |25 | 6
27.03.2000 |27 | 1
(4 rows)
No file was uploaded with this report
