[BUGS] BUG #5765: pg_dump fail to find upper case table name
The following bug has been logged online: Bug reference: 5765 Logged by: Cristiano Email address: sumar...@gmail.com PostgreSQL version: 8.4.4 Operating system: Linux Description:pg_dump fail to find upper case table name Details: The following command line did not worked. Using a table with lower case chars( no quoting ) works. Also happen on pg_dump windows version. Tested on 8.4.4 and 8.4.3 pg_dump --host www --port 5432 --username postgres --format plain --column-inserts --verbose --file "streetTypes.sql" --table public."streetTypes" "geocoding-dev" Password: pg_dump: No matching tables were found pg_dump: *** aborted because of error Test case: just create an table that need quoting. CREATE TABLE "Test"() WITH ( OIDS=FALSE ); Call pg_dump to export. pg_dump --host localhost --port 5432 --username postgres --format plain --column-inserts --verbose --file "test.sql" --table public."Test" "test-db" -- 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 #5765: pg_dump fail to find upper case table name
On 24.11.2010 13:34, Cristiano wrote: pg_dump --host www --port 5432 --username postgres --format plain --column-inserts --verbose --file "streetTypes.sql" --table public."streetTypes" "geocoding-dev" Password: pg_dump: No matching tables were found pg_dump: *** aborted because of error Test case: just create an table that need quoting. CREATE TABLE "Test"() WITH ( OIDS=FALSE ); Call pg_dump to export. pg_dump --host localhost --port 5432 --username postgres --format plain --column-inserts --verbose --file "test.sql" --table public."Test" "test-db" Manual says (at the bottom of http://www.postgresql.org/docs/8.4/static/app-pgdump.html): To specify an upper-case or mixed-case name in -t and related switches, you need to double-quote the name; else it will be folded to lower case (see Patterns). But double quotes are special to the shell, so in turn they must be quoted. Thus, to dump a single table with a mixed-case name, you need something like $ pg_dump -t '"MixedCaseName"' mydb > mytab.sql -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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 #5765: pg_dump fail to find upper case table name
"Cristiano" wrote: > Operating system: Linux > Description: pg_dump fail to find upper case table name > --table public."streetTypes" Linux is eating the quotes. Try: --table public.'"streetTypes"' While a bit confusing, this is not a bug in the code. Perhaps the documentation should specifically mention it -Kevin -- 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 #5765: pg_dump fail to find upper case table name
Heikki Linnakangas wrote: > Manual says (at the bottom of > http://www.postgresql.org/docs/8.4/static/app-pgdump.html): > >> To specify an upper-case or mixed-case name in -t and related >> switches, you need to double-quote the name; else it will be >> folded to lower case (see Patterns). But double quotes are >> special to the shell, so in turn they must be quoted. Thus, to >> dump a single table with a mixed-case name, you need something >> like >> >> $ pg_dump -t '"MixedCaseName"' mydb > mytab.sql Perhaps some of that should be moved up to the definition of the -t switch? It wouldn't seem too out of place to me to put it somewhere near this sentence: | When using wildcards, be careful to quote the pattern if needed to | prevent the shell from expanding the wildcards. While examples are useful, information which is only provided there is easily missed when someone goes to read up on a particular switch. -Kevin -- 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 #5764: installation error (incomplete process)
"abraham camacho" wrote: > PostgreSQL version: 8.0.0 Yikes. That was released almost six years ago and went out of support last month. There are 26 maintenance releases since that "dot 0" release to fix bugs and security problems. http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy http://www.postgresql.org/support/versioning http://www.postgresql.org/docs/8.0/static/release.html > I am receiving the next 2 messages when I try to install the > MoteView Software that includes PstgreSQL V8.0: This, however, doesn't sound likely to be a PostgreSQL bug (even one of the hundreds fixed in 8.0.26). It is more likely a problem in the installation procedure provided by MoteView. You might want to contact them first. > I have deactivated the mcafee firewall in my PC but still it > doesnot work. Sometimes a firewall causes problems unless it is actually uninstalled. "Deactivating" them often leaves quite a bit of intrusive code running. -Kevin -- 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 #5765: pg_dump fail to find upper case table name
Hello, Kevin. You wrote: KG> Heikki Linnakangas wrote: KG> >> Manual says (at the bottom of >> http://www.postgresql.org/docs/8.4/static/app-pgdump.html): >> >>> To specify an upper-case or mixed-case name in -t and related >>> switches, you need to double-quote the name; else it will be >>> folded to lower case (see Patterns). But double quotes are >>> special to the shell, so in turn they must be quoted. Thus, to >>> dump a single table with a mixed-case name, you need something >>> like >>> >>> $ pg_dump -t '"MixedCaseName"' mydb > mytab.sql KG> KG> Perhaps some of that should be moved up to the definition of the -t KG> switch? It wouldn't seem too out of place to me to put it somewhere KG> near this sentence: KG> KG> | When using wildcards, be careful to quote the pattern if needed to KG> | prevent the shell from expanding the wildcards. +100 KG> KG> While examples are useful, information which is only provided there KG> is easily missed when someone goes to read up on a particular KG> switch. KG> KG> -Kevin -- With best wishes, Pavel mailto:pa...@gf.microolap.com -- 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 #5766: regexp \y doesn't work properly when a word starts on ends with a UTF-8 char
The following bug has been logged online:
Bug reference: 5766
Logged by: Grzegorz Daniluk
Email address: gdani...@gmail.com
PostgreSQL version: 9.0.1
Operating system: Windows 7 64-bit
Description:regexp \y doesn't work properly when a word starts on
ends with a UTF-8 char
Details:
select regexp_replace('Foo Pasaż Bar', E'\\yPasaż\\y', '');
Above query doesn't replace the word 'Pasaż'. It returns full 'Foo Pasaż
Bar' string, when the correct behavior is to return 'Foo Bar'.
When the 'ż' is replaced with normal ASCII character like 'z',
regexp_replace works as expected.
My db details:
ENCODING = 'UTF8'
LC_COLLATE = 'Polish_Poland.1250'
LC_CTYPE = 'Polish_Poland.1250'
--
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 #5766: regexp \y doesn't work properly when a word starts on ends with a UTF-8 char
"Grzegorz Daniluk" writes:
> select regexp_replace('Foo Pasaż Bar', E'\\yPasaż\\y', '');
> Above query doesn't replace the word 'Pasaż'. It returns full 'Foo Pasaż
> Bar' string, when the correct behavior is to return 'Foo Bar'.
Is this problem limited to \y, or do other regex operations that depend
on locale-specific character classification also not work for you?
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] BUG #5767: Memory Leak
The following bug has been logged online: Bug reference: 5767 Logged by: Darryl Pye Email address: darryl...@hotmail.com PostgreSQL version: 9.01 Operating system: Windows Server 2008 Description:Memory Leak Details: A single postgres process appears to be constantly growing in memory usage until it reaches 100% of memory on the machine. I have rebooted the server and the problem goes away but then a single postgres.exe process continues to eat memory until it uses all available ram then i have to restart again. Machine has 4 gig of ram available. I am able to watch the process grow constantly at approximately 8kb every second. Until it reaches 4gig. I have made the following configuration changes from default shared_buffers = 1GB wal_buffers = 1MB effective_cache_size = 2GB -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
