Re: [BUGS] Error with refering to the header files
"Ibrahim, Karim Aly Mohi Eldin" writes: > Im new to postgres and I have some C files that execute sql commands in the > early parser stage.. > It has to include #include "libpq-fe.h" which is in the "interface" folder > not the "include" folder so I edited the make file like following: Not sure about the specific error you're getting, but ISTM you're going about this all wrong anyway. Using libpq from inside the backend is, unless you're trying to do dblink-like remote access, just broken. Consider SPI instead if you want to issue SQL-level queries. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] 9.2beta1 regression: pg_restore --data-only does not set sequence values any more
Hello all,
while packaging 9.2 beta 1 for Debian/Ubuntu the postgresql-common
test suite noticed a regression: It seems that pg_restore --data-only
now skips the current value of sequences, so that in the upgraded
database the sequence counter is back to the default. This can lead to
rather serious data errors.
Reproducer:
* Create a db and sequence:
$ createdb test
$ psql test -c "CREATE SEQUENCE odd10 INCREMENT BY 2 MINVALUE 1 MAXVALUE 10
CYCLE"
CREATE SEQUENCE
* Advance it two steps:
$ psql --cluster 9.2/main -Atc "SELECT nextval('odd10')" test
1
$ psql --cluster 9.2/main -Atc "SELECT nextval('odd10')" test
3
* Dump schema and "test" data:
$ pg_dumpall -s > /tmp/schema
$ pg_dump -Fc test > /tmp/test.dump
* Drop db:
$ dropdb test
* Restore DB:
$ psql template1 < /tmp/schema
$ pg_restore --data-only -d postgres /tmp/test.dump
* Check the counter:
$ psql -Atc "SELECT nextval('odd10')" test
1
This is wrong, it should be "5", from the original database. This
worked all the way up to 9.1.
With "pg_restore /tmp/test.dump" (i. e. a full dump), you see
SELECT pg_catalog.setval('odd10', 3, true);
in the dump, but it is not present in the output of
"pg_restore --data-only /tmp/test.dump". However, when I use the 9.1
version, it works:
$ /usr/lib/postgresql/9.1/bin/pg_restore --data-only /tmp/test.dump | grep
setval
SELECT pg_catalog.setval('odd10', 3, true);
Thanks!
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
[BUGS] BUG #6640: pg_dump does not always dump data of tables marked as editable in extension
The following bug has been logged on the website: Bug reference: 6640 Logged by: Regina Obe Email address: l...@pcorp.us PostgreSQL version: 9.1.3 Operating system: Any Description: This seems to be only an issue if a user individually chooses to backup a table marked as editable in an extension, but works fine if full backup is chosen. The particular extension in question here is PostGIS. Please refer to: http://trac.osgeo.org/postgis/ticket/1815 for details. In short -- if I do a full backup of a database, a table marked as editable gets its data backed up as expected, but if I try to backup a schema the table is in or the table itself, pg_dump does not dump anything. -- 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 #6639: Manual uses boldface where it says italic, and monospace where it says boldface
The following bug has been logged on the website: Bug reference: 6639 Logged by: Ian Email address: iain.dal...@gmail.com PostgreSQL version: 9.1.3 Operating system: GNU/Linux Description: The URL http://www.postgresql.org/docs/9.1/interactive/notation.html lays out the notation used in the rest of the book, but it appears to be out of date with the stylesheet, as the differences noted in the subject apply. -- 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 #6642: Spanish collation fault
The following bug has been logged on the website: Bug reference: 6642 Logged by: T J Carrasco Email address: tulio.carra...@gmail.com PostgreSQL version: 9.1.3 Operating system: Ubuntu 12.04 LTS Description: In Spanish every vowel has the same precedence value even with or without any type of accent, so: a = á = ä = A = Á = Ä With OS locale = lc_collate = lc_ctype = es_ES.UTF-8 then: CREATE TABLE test(id integer PRIMARY KEY, dad text, mum text, name text); INSERT INTO test VALUES (1, 'león','valencia', 'josé'), (2, 'leon', 'mendoza', 'juan'), (3, 'león', 'valárd', 'jose'), (4, 'león','válencia', 'jos'), (5, 'león', 'mendoza', 'jua'), (6, 'leon', 'valencia', 'josie'), (7, 'león', 'valencia', 'josie'), (8, 'leo','zara', 'juan'), (9, 'león','Valencia', 'jos'); SELECT * FROM test order by dad, mum, name; We obtain: id | dad | mum | name ---+--+--+--- 8 | leo | zara | juan 2 | leon | mendoza | juan 6 | leon | valencia | josie 5 | león | mendoza | jua 3 | león | valárd | jose 1 | león | valencia | josé 7 | león | valencia | josie 9 | león | Valencia | jos 4 | león | válencia | jos (9 rows) Which doesn´t accomplish with Spanish collation. It should be something like this: id | dad | mum | name ---+--+--+--- 8 | leo | zara | juan 2 | leon | mendoza | juan 5 | león | mendoza | jua 3 | león | valárd | jose 4 | león | válencia | jos 9 | león | Valencia | jos 1 | león | valencia | josé 6 | leon | valencia | josie 7 | león | valencia | josie (9 rows) In which due dad column has the same value it uses the mum column and if they also have the same value then it should use the name column. Thanks in advance for your help. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
