Re: [BUGS] BUG #6519: Server doesn't listem
On 05-03-2012 09:25, llim...@hotmail.com wrote: Bom dia , queria um ajuda , acontece muito de dar esse erro , Server doesnt listen , quando tenta conectar ao banco de dados , geralmente so resolve formatando o PC , por favor se puderem me ajudar , ficarei grato , nao gostaria de parar de usar essa otima ferramente de banco de dados. Isso não é um erro do PostgreSQL. Faça a sua pergunta na lista de usuários brasileiros [1]. Parece-me que o seu problema está na configuração do PostgreSQL (vide parâmetro listen_addresses [2] e arquivo pg_hba.conf [3]). [1] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral [2] http://www.postgresql.org/docs/9.1/static/runtime-config-connection.html [3] http://www.postgresql.org/docs/9.1/static/auth-pg-hba-conf.html -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- 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 #6444: Postgresql crash
On 09-02-2012 17:26, Petr Jediný wrote: If it's still needed I can provide the table dump, it's about 543M gziped. No, that bug was already fixed in our repository. I advise you to stay with 8.4.9 until 8.4.11 is released (in a month or so) unless you are suffering with another bug that was fixed in 8.4.10 (in this case, just get the patch [1] and build a custom version). [1] http://git.postgresql.org/pg/commitdiff/81f4e6cd27d538bc27e9714a9173e4df353a02e5 -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- 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 #6412: psql fe-connect truncate passwords
On 27-01-2012 23:15, agr...@gmail.com wrote: When psql prompts for a password, it only reads the first 100 characters of the password. The limit in fe-connect.c (for when .pgpass is used) is weirder, a seemingly arbitrary 320 bytes for all fields combined. Other (postgresql-jdbc, PyGreSQL, etc.) have no problem with a 512-byte password. It would be nice to have these limits controlled by a constant, and for the command to give an error or warning when a password is truncated. I don't see it as a bug but a limitation. Why do you need such a long password? If you are not comfortable with this reasonable limit, look at fe-connect.c - PasswordFromFile() and change the LINELEN. More to the point, AFAICS all of the PostgreSQL client prompts are limited to 100 bytes (look at simple_prompt function); letting 220 bytes for host, port, database, and user. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- 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 #6412: psql fe-connect truncate passwords
On 28-01-2012 14:32, Andy Grimm wrote: IMHO, there is a subtle difference here. If psql raised an error message on passwords exceeding 100 characters, I would understand your perspective, but I think that simply truncating the password and continuing on is a bug. I also think that hard-coding the number 100 in several places is simply poor practice which should be corrected, and that if there's good reason for that to be the password length limit, it should be uniformly enforced. It is uniform on all of the bundled client tools. The source can always be improved; such a constant is one of those improvements. The password is not of my choosing. It's an autogenerated sha hash of an RSA key, and i've simply been the key to use. While I agree that it's generally impractical to use such a long password at the command line, more than 99% of the use of this password is programmatic, and if I complain to the author that the password is too long, he'll respond it works for me with JDBC; you are using broken tools. So the broken part is the password file, right? I won't expect someone with such a long password typing or (of course) copy/paste it, will I? Again, patches are welcome. I looked at the code before I wrote up the issue, and I have written and tested a patch. I've posted it here: https://bugzilla.redhat.com/attachment.cgi?id=558061 Please, post a patch here, we don't follow other bug trackers. Perhaps I should just submit the patch to pgsql-hackers ? I'm new to the pgsql bug interaction process, so my apologies if filing a bug was not the appropriate way to present the issue. I get Internal Server Error messages when I attempt to subscribe to any of the pgsql mailing lists, so this makes communication with the lists difficult. Bugs are tracked here but when it is not a bug but an improvement, we just redirect this thread to -hackers. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- 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 #6413: pg_relation_size wont work on table with upper case chars
On 28-01-2012 13:16, ja...@stev.org wrote:
pg_relation_size('Attempts')
and
pg_relation_size('attempts')
pg_relation_size('Attempts')
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
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] One question about VACUUMDB command - please
On 26-01-2012 05:31, sasa.petro...@falc.biz wrote: Why this comand that I write belove ask me for password, even I create user into DB with same password like user on my server that execute this command? PostgreSQL doesn't inherit authentication properties from operational system. Instead you could use environment variables [1], pgpass.conf file [2] or even tune pg_hba.conf [3] to not ask the password for certain host/user/database. [1] http://www.postgresql.org/docs/current/static/libpq-envars.html [2] http://www.postgresql.org/docs/current/static/libpq-pgpass.html [3] http://www.postgresql.org/docs/current/static/auth-pg-hba-conf.html -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- 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 #6386: PITR never find a consistent recovery point
On 06-01-2012 15:16, max.k...@atip.de wrote: FATAL: requested recovery stop point is before consistent recovery point. One system is configured as standby, performing stream and WAL replication. Another system is running in primary mode. I have verified that the standby system performed the basebackup successfully. Hours later I did like to perform a PITR. I use a target_time which is one hour later than stop_basebackup_time. In spite of that fact, i've got the error message. It doesn't seem a bug. Are you sure the time choosen is *after* you send a pg_stop_backup()? -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- 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 #6353: If there is invalid line in pg_hba.conf, DB start fails without any nofice and no logs in pgstartup.
On 22-12-2011 12:53, er...@eurotel.com.tr wrote: If I add this line to pg_hba.conf, it causes a silent startup failure: localallbackup 127.0.0.1/32 trust There is a linux user backup on this system. After adding this line and issue pg_ctl reload it signals server successfully, no errors. But if I stop db server, I can not start db anymore. Strangely no log exists in pgstartup.log. Even I start with -d 5 debug param, it exists after logging shutdown message. Debugging with gdb didn't help. After removing the line added above in pg_hba.conf, db starts. This is not a bug. Did you check your server logs (pgstartup.log must be the pg_ctl output)? I got: LOG: invalid authentication method 127.0.0.1/32 CONTEXT: line 80 of configuration file /home/euler/pg90/data/pg_hba.conf FATAL: could not load pg_hba.conf If you don't have logging_collector enabled, you should get the above message in your terminal. Problem is: instead of local you should use host. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- 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 #6327: Prefix full-text-search fails for hosts with complicated names
On 05-12-2011 09:40, marcin.kasper...@mekk.waw.pl wrote: 'goog:*' matches google.com but 'e-goog:*' does not match e-google.com It is a known limitation. The text search parser ignores some uncommon cases. See TODO and archives. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- 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 #6327: Prefix full-text-search fails for hosts with complicated names
On 05-12-2011 12:29, Marcin Kasperski wrote: 'goog:*' matches google.com but 'e-goog:*' does not match e-google.com It is a known limitation. The text search parser ignores some uncommon cases. See TODO and archives. Could you suggest me what to look for? I don't see anything related on http://wiki.postgresql.org/wiki/Todo#Text_Search and I already tried numerous searches to find similar problems, but failed to locate anything related… Improve handling of plus signs in email address user names, and perhaps improve URL parsing Search for url text search parser in the archives. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- 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] Timezone issues with Postrres
On 21-09-2011 13:38, Robert Haas wrote: On Wed, Sep 21, 2011 at 3:16 AM, pratikchiraniapratik.chira...@hp.com wrote: The command clearly does not return '--with-system-tzdata'. I am using Windows server 2008 R2. The TZ data must be working fine as other applications on the OS are working fine. The issue is also reproducible on Postgre version 8.3. You said that your PostgreSQL time zone was set to UTC-6. Are you sure that's the case? What's the output from 'SHOW timezone'? Also, what's the system time zone set to? The reason I ask is because, for me, setting the time zone to UTC-6 gives me a time that is six hours AHEAD of UTC, which wouldn't be appropriate for South America: rhaas=# select now() at time zone 'utc', now() at time zone 'utc -6'; timezone | timezone + 2011-09-21 16:31:26.082048 | 2011-09-21 22:31:26.082048 (1 row) That's odd because there is no 'utc -6' timezone. Moreover, 'utc+6' [1] should be 6 hours ahead 'utc'. I don't read the code to confirm if it is a bug or a correct behavior (as I don't understand much about the insane timezone rules). The rules for interpreting time zone specifications are arcane enough to make me suspect that this isn't a bug even though it seems rather odd, but in any case it would be useful to know how many hours PostgreSQL's timestamp is behind (or ahead of) UTC and similarly for the operating system. I think the OP is talking about one of these timezones: euler=# select * from pg_timezone_names where utc_offset = '-06:00:00'; name | abbrev | utc_offset | is_dst --+++ Mexico/BajaSur | MDT| -06:00:00 | t Pacific/Galapagos| GALT | -06:00:00 | f US/Mountain | MDT| -06:00:00 | t Canada/Mountain | MDT| -06:00:00 | t Canada/Saskatchewan | CST| -06:00:00 | f Canada/East-Saskatchewan | CST| -06:00:00 | f America/Swift_Current| CST| -06:00:00 | f America/Denver | MDT| -06:00:00 | t America/Chihuahua| MDT| -06:00:00 | t America/Belize | CST| -06:00:00 | f America/Costa_Rica | CST| -06:00:00 | f America/Shiprock | MDT| -06:00:00 | t America/Managua | CST| -06:00:00 | f America/Tegucigalpa | CST| -06:00:00 | f America/Guatemala| CST| -06:00:00 | f America/Cambridge_Bay| MDT| -06:00:00 | t America/Regina | CST| -06:00:00 | f America/Ojinaga | MDT| -06:00:00 | t America/Yellowknife | MDT| -06:00:00 | t America/El_Salvador | CST| -06:00:00 | f America/Edmonton | MDT| -06:00:00 | t America/Mazatlan | MDT| -06:00:00 | t America/Boise| MDT| -06:00:00 | t America/Inuvik | MDT| -06:00:00 | t MST7MDT | MDT| -06:00:00 | t Navajo | MDT| -06:00:00 | t Etc/GMT+6| GMT+6 | -06:00:00 | f (27 registros) ... and I suspect the is_dst is true. [1] http://en.wikipedia.org/wiki/UTC%2B6 -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- 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] Timezone issues with Postrres
On 16-09-2011 01:57, pratikchirania wrote: Time is being interpreted incorrectly when I set time zone to UTC -6 (Central America). Time shown when I query SELECT NOW() is 1 hour ahead of system time. PS: Central america does not have daylight saving. That might not be the issue. It is not a bug. Was is the exact postgresql version? How old is your installation? It seems your PostgreSQL or OS tzdata is not up to date. If 'pg_config --prefix' command has '--with-system-tzdata' update your installation to the latest minor version (for example, 8.4 - 8.4.8) else update your OS tzdata and restart the PostgreSQL. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- 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 #6041: Unlogged table was created bad in slave node
Em 26-05-2011 08:37, Emanuel escreveu: Description:Unlogged table was created bad in slave node Unlogged table contents are not available to slave nodes [1]. postgres=# select * from voidy ; ERROR: could not open file base/12071/17034: No existe el archivo o directorio I think we should emit the real cause in those cases, if possible (not too much overhead). The message would be Unlogged table content is not available in standby server. [1] http://www.postgresql.org/docs/9.1/static/sql-createtable.html -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- 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 #6017: COPY from CSV file, WITH CSV HEADER fields order not respected
Em 09-05-2011 15:07, pedro mg escreveu: # COPY test1 FROM '/tmp/test1.csv' WITH CSV HEADER Why don't you specify the columns? COPY test1 (key, c2, c1) FROM '/tmp/test1.csv' WITH CSV HEADER -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- 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 #6013: PostgreSql Lento
Em 07-05-2011 00:10, Denilson Costa escreveu: O PostgreSql no windows 2003 esta muito lento para gerar relatorio no meu sistema. Utilizo um sistema ERP especifico para concessionaria de veiculos. E alguns relatorios o mesmo fica lento. Isto *não* é um bug. O que você precisa é de uma consultoria para executar a manutenção adequada do SGBD; ou, se quiser, pode utilizar a lista de discussão brasileira pgbr-geral [1] como fonte de informação sobre o seu problema. [1] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- 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 #6009: Duvida
Em 05-05-2011 15:57, Nestor escreveu: The following bug has been logged online: Bug reference: 6009 Logged by: Nestor Email address: nestord...@gmail.com PostgreSQL version: 9.0.4-1 Operating system: Windows Description:Duvida Details: Boa tarde, estou tentando instalar o POSTGRE, porem no setup aparece o campo PASSWORD e RETYPE PASSWORD, aonde informo uma senha aletória e redigito ela, porem aparece a seguinte mensagem: THE PASSWORD SPECIFIED WAS INCORRECT. PLEASE ENTER THE CORRECT PASSWORD FOR THE POSTGRES WINDOWNS USER ACCOUNT Isto *não* é um bug. Postgres ou PostgreSQL. Esta é uma lista exclusivamente de língua inglesa. Para dúvidas em português, utilize pgbr-geral [1]. Quanto ao seu problema, o PostgreSQL já estava instalado na sua máquina? Ele estava sendo utilizado? Caso não, basta excluir o usuário do sistema operacional com o comando 'net user postgres /delete' no prompt do DOS e tente instalar novamente. [1] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- 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 #5951: ERRO NO INICIO DA INSTALACAO
Em 25-03-2011 17:59, DIEGO BALAN escreveu: aparece a mensagem please provide a password for the database superuser and service account. if the service account already exists in windows, you must enter the current password for the account. if the account does not exist, it will be created when you click nex quando eu tento instalar o programa, bem no inicio da instalacao, mas eu nunca instalei o postgree no pc, e o windows nao esta com senha de usuario? o que fazer??? This is not a bug. It is a english only list. Você leu a mensagem? A conta existe? Se ela não existir, o instalador irá criá-la; se existir, você terá que fornecer a senha que colocou. Talvez outro programa tenha instalado o postgres, sem que você saiba. Caso a conta exista e você não lembra da senha, você pode remover o usuário com o comando 'net user postgres /delete' no prompt do DOS. E depois, executar o instalador novamente. O nome do software não é postgree e sim postgres ou postgresql. -- Euler Taveira de Oliveira http://www.timbira.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 #5934: postgresql.conf: optional equal sign
Em 16-03-2011 12:25, Frederic Junod escreveu: Error: Invalid line 502 in /etc/postgresql/8.4/main/postgresql.conf: »listen_addresses '*'« AFAICS it is a Debian bug not a PostgreSQL one. I already hit it once but didn't investigate the problem. [looking at debian bugs...] It seems you already reported the bug [1] for Debian guys. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618583 -- Euler Taveira de Oliveira http://www.timbira.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] CREATEROLE does not permit commenting on newly-created roles
Em 07-03-2011 16:53, Owen Jacobson escreveu: psql:repro.sql:2: ERROR: must be member of role commented_role to comment upon it This isn't a bug; let say it is a limitation (and a documented one [1]). Unfortunately only the role, superuser or its members can add/drop comments. [1] http://www.postgresql.org/docs/9.0/static/sql-comment.html -- Euler Taveira de Oliveira http://www.timbira.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 #5878: BTREE_BUILD_STATS causes 'make check' to fail
Em 10-02-2011 09:56, Jan-Peter Seifert escreveu: However, as long as I have BTREE_BUILD_STATS defined, 'make check' fails on me with the following message: It is a bug. The attached patch fixes it. I didn't investigate when it was broken; maybe one or two releases ago when someone reorganizes the header files. Those debug macros deserve a refactor but nobody bothers to do it yet. -- Euler Taveira de Oliveira http://www.timbira.com/ diff --git a/src/backend/access/nbtree/nbtree.c b/src/backend/access/nbtree/nbtree.c index 558ace1..ba01874 100644 *** a/src/backend/access/nbtree/nbtree.c --- b/src/backend/access/nbtree/nbtree.c *** *** 31,36 --- 31,37 #include storage/lmgr.h #include storage/predicate.h #include storage/smgr.h + #include tcop/tcopprot.h #include utils/memutils.h diff --git a/src/backend/access/nbtree/nbtsort.c b/src/backend/access/nbtree/nbtsort.c index e02f008..fd0e86a 100644 *** a/src/backend/access/nbtree/nbtsort.c --- b/src/backend/access/nbtree/nbtsort.c *** *** 70,75 --- 70,76 #include access/nbtree.h #include miscadmin.h #include storage/smgr.h + #include tcop/tcopprot.h #include utils/rel.h #include utils/tuplesort.h -- 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 #5819: Translation Error of initdb's zh_CN.po
Em 07-01-2011 03:52, yulei escreveu: Hi, I am a chinse , i found the src/bin/initdb/po/zh_CN.po have a translation error in line 608. Could you provide a new zh_CN.po with the corrected strings? Grab the PO file (initdb-zh_CN) from the 9.0 branch [1] and post it to Patch Tracker [2]. [1] http://babel.postgresql.org/ [2] http://pgfoundry.org/tracker/?group_id=164 -- Euler Taveira de Oliveira http://www.timbira.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] Problems with max_connections parameter
Jorge Augusto Meira escreveu: The test program is running in other 5 client machines. In the logs of my test program, the max_connection parameter limit is never reached. How could the test program know? Indeed it doesn't. Are you using some delay between one test and another one? I would be a good idea, specially if you're restarting the PostgreSQL between tests. -- Euler Taveira de Oliveira http://www.timbira.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] Problems with max_connections parameter
Jorge Augusto Meira escreveu: This is a bug? You don't provide sufficient information. PostgreSQL version? Error message? Talking about your problem, are you sure you're not reaching max_connections? Did you check the logs? -- Euler Taveira de Oliveira http://www.timbira.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 #5778: pgAdminIII 1.12.1 Japanese Translation File
carriager escreveu: pgAdminIII 1.12.1 (on Windows XP Japanese), column property, error at ALTER TABLE ... ALTER COLUMN ... SET STORAGE ...; It was already fixed [1]. It will be in the next pgAdmin version (1.12.2). [1] http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commit;h=6c0bbd89869939e1b48e9235c30d9601347316b8 -- Euler Taveira de Oliveira http://www.timbira.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 #5656: parameter 'client_min_messages' accept values not listed in enumvals
Tom Lane escreveu:
thommy der.tho...@gmx.net writes:
I just came across a small inconsistency:
pg=# select enumvals from pg_settings where name='client_min_messages';
enumvals
---
{debug5,debug4,debug3,debug2,debug1,log,notice,warning,error}
It's intentional that PANIC isn't listed there (nor is FATAL),
on the grounds that it's not really a useful setting.
Fine. But shouldn't we remove these options from docs and/or code?
--
Euler Taveira de Oliveira
http://www.timbira.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 #5656: parameter 'client_min_messages' accept values not listed in enumvals
Bruce Momjian escreveu:
We are basically reusing the same validation code for this and other
min_messages settings.
No, we have two enums ({client,server}_message_level_options); I don't
understand why we should have these options in client_min_messages enum.
--
Euler Taveira de Oliveira
http://www.timbira.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 #5656: parameter 'client_min_messages' accept values not listed in enumvals
Tom Lane escreveu: ISTM your argument can be reduced to there should be no hidden values ever, but I doubt we're going to buy that. No, the hidden values has their use case (hiding legal values that we don't want to expose, for example, true/false, 0/1, yes/no). My point is if they are not useful let's rip them to not confuse people. -- Euler Taveira de Oliveira http://www.timbira.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 #5652: Optimizer does wrong thing with partitioned tables
Mladen Gogala escreveu: Optimizer chooses to scan each partitioned table sequentially, instead of using the available index: This is not a bug. How would the optimizer know that the maximum value is in that specific partition? There is neither a global index for a partitioned table nor an optimizer artifact to know aggregate information before scanning all of the partitions. Maybe when we have a better support for table partitioning such optimizer artifact would be implemented but don't hold your breath. -- Euler Taveira de Oliveira http://www.timbira.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] Dúvida
Anderson Costa escreveu: *Gostaria de saber como faço a integração do BD PostgreSQL com o Netbeans.* * Esse não é o local apropriado para sua pergunta. É uma lista de relato de defeitos e não um local para tirar dúvidas de usuários; além disso, trata-se de uma lista na língua inglesa. Tente a lista da comunidade brasileira em [1]. [1] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Euler Taveira de Oliveira http://www.timbira.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 #5629: ALTER SEQUENCE foo START execute a RESTART
Tom Lane escreveu: I'm not inclined to go and retroactively document that these spellings are possible but deprecated in the old branches. I think that would just confuse matters even more. Is it worth preventing that sloppy implementation in the old branches? -- Euler Taveira de Oliveira http://www.timbira.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] help pleas
Mohamed Fadul escreveu: [r...@localhost ~]# pg_restore -d esoko_local -e -1 -U postgres -v /root/backupjul30 pg_restore: invalid option -- 1 Try pg_restore --help for more information. You didn't inform the PostgreSQL version but I bet you're using = 8.1.x. In this case, that option does not exist. -- Euler Taveira de Oliveira http://www.timbira.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 #5342: Error
Shilpa.R escreveu: select agegrp, cartype, risk, count(*) as count from trset group by risk, grouping sets ((agegrp,cartype)) This is not a bug. If you had searched the fine manual, you would figure out that grouping sets is not supported by PostgreSQL yet. -- Euler Taveira de Oliveira http://www.timbira.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] Cache lookup failure for index during pg_dump
Tom Lane escreveu: The window for this sort of thing isn't very large, because the first thing pg_dump does is acquire AccessShareLock on every table it intends to dump, and past that point it won't be possible for anyone to modify the table's DDL. But it can happen. I did not see it documented anywhere. Should we at least add a comment at the top of pg_dump documenting this behavior? Attached is a proposed patch using your own words. -- Euler Taveira de Oliveira http://www.timbira.com/ *** src/bin/pg_dump/pg_dump.c.orig 2010-02-19 23:22:56.0 -0200 --- src/bin/pg_dump/pg_dump.c 2010-02-19 23:43:08.0 -0200 *** *** 11,16 --- 11,27 * script that reproduces the schema in terms of SQL that is understood * by PostgreSQL * + * Note that pg_dump runs in a serializable transaction, so it sees a + * consistent snapshot of the database including system catalogs. + * However, it relies in part on various specialized backend functions + * like pg_get_indexdef(), and those things tend to run on SnapshotNow + * time, ie they look at the currently committed state. So it is + * possible to get 'cache lookup failed' error if someone performs DDL + * changes while a dump is happening. The window for this sort of thing + * is from the beginning of the serializable transaction to + * getSchemaData() (when pg_dump acquires AccessShareLock on every + * table it intends to dump). It isn't very large but it can happen. + * * IDENTIFICATION * $PostgreSQL$ * -- 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 #5331: Integer overflow in tmie counter
Kajetan Abt escreveu: Amusingly, the counter on the lower right of the SQL-input window sometimes shows negative numbers counting up, probably some sort over overflow. No harm done though. If you don't provide more details (test case) it's hard to say if it's a bug or not. -- Euler Taveira de Oliveira http://www.timbira.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] Postgresql Relations disappear
sergio dominguez escreveu: I started to work with postgresql but i find that all the relations I create disappear when I quit (\q) This is not a bug. I bet your tables are loaded into a schema that is not in the search_path. -- Euler Taveira de Oliveira http://www.timbira.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 #5329: postmaster fails to start because of an erroneous pg_hba.conf, but doesn't output any error
Olivier Jeannet escreveu: I had a hard time finding the problem, as nothing is ouput on the command line or in the logs. Ugh? I got this in 8.4 or earlier version. Are you checking the right log file? LOG: invalid authentication method 127.0.0.1/32 CONTEXT: line 74 of configuration file /a/data/pg_hba.conf FATAL: could not load pg_hba.conf -- Euler Taveira de Oliveira http://www.timbira.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] Failed to run initdb - not resolved bug 5130
Tomas Studva escreveu: I have some time now. I've tried to compile postgres from CVS but wihout success. I don't have visual studio 2005 installed so I've tried eclipse + MinGw. I checked out postgres from cvs branch REL8_4_STABLE. But I wasn't able to compile it. I don't know how to configure builders to launch makefiles or what to do. Take a look at [1][2]. [1] http://wiki.postgresql.org/wiki/Working_with_Eclipse [2] http://www.postgresql.org/docs/faqs.FAQ_MINGW.html -- Euler Taveira de Oliveira http://www.timbira.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 #5295: Function OUT parameters names and data types skewed with IN parameters
Bruce Patin escreveu: Yields the following arguments, as displayed in phpPgAdmin when editing the function: This is not a PostgreSQL bug. Don't know if the phpPgAdmin developers read this list but, in any case, try to report it in the right place [1]. [1] http://phppgadmin.sourceforge.net/?page=support -- Euler Taveira de Oliveira http://www.timbira.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 #5216: pgFouine 1.1 not working correctly, when LC_MESSAGES is es_ES.UTF-8
Guillaume Smet escreveu: pgFouine doesn't support lc_message other than english. What about adding a translation table in pgFouine to catch those cases too? -- Euler Taveira de Oliveira http://www.timbira.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 #5145: Complex query with lots of LEFT JOIN causes segfault
Bernt Marius Johnsen escreveu: The below query generated by the Random Query Generator (https://launchpad.net/randgen) causes a segfault. It was caused running Could you get a core dump and post the gdb backtrace? $ ulimit -c unlimited $ pg_ctl start $ psql -c my query goes here mydb $ gdb /path/to/postgres $PGDATA/core (gdb) bt . . . (gdb) quit -- Euler Taveira de Oliveira http://www.timbira.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 #5021: ts_parse doesn't recognize email addresses with underscores
Robert Haas escreveu:
I'm not real familiar with ts_parse(), but I'm thinking that it
doesn't have any special casing for email addresses and is just
intended to parse text for full-text-search - in which case splitting
on _ is a pretty good algorithm.
It is a bug. The tsearch claims to identify types of tokens but it doesn't
correctly identify any valid e-mail addresses. As Dan stated ts_parse() fails
to recognize an e-mail address. For example, foo+...@baz.com is a valid e-mail
but the function fails to report that.
It is not that simple to identify an e-mail address that agrees with RFC. As
that code is a state machine, IMHO it decides too early (when it finds _) that
that string is not an e-mail address. AFAIR, that's not an one-line fix.
euler=# select distinct token as email from ts_parse('default',
'foo@baz.com');
email
─
foo@baz.com
(1 row)
euler=# select distinct token as email from ts_parse('default',
'foo+...@baz.com');
email
─
foo
+
b...@baz.com
(3 rows)
euler=# select distinct token as email from ts_parse('default',
'foo_...@baz.com');
email
─
foo
b...@baz.com
_
(3 rows)
--
Euler Taveira de Oliveira
http://www.timbira.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 #5075: Text Search parser does not identify xml tag when attribute name's contains underscore
Marek Lewczuk escreveu:
Please execute following example:
select * from ts_debug('english', 'img width=182 height=120
align=right style=margin: 0px 0px 5px 5px; test_aa=26461/')
As the result you will see, that img/ is not identified as XML tag, but
rather splitted as words, blank spaces etc. The reason for that is the fact,
that last attribute test_aa contains underscore in its name - when the
underscore is removed, then img tag is properly identified as XML tag.
XML definition allows using underscore in tag and attribute names.
The problem is we already allow it in tag names but not in attribute names. So
the proper fix is to allow underscore when the state is TPS_InTag; according
to XML spec [1], the underscore is a valid character in attribute names.
A possible downside is that we don't have underscores in HTML attribute names.
In this case, should it fail? I don't think so but...
The problem exists in 8.3, 8.4 and HEAD. It is a trivial fix so I think there
isn't a problem to back-patch it.
[1] http://www.w3.org/TR/REC-xml/#sec-common-syn
--
Euler Taveira de Oliveira
http://www.timbira.com/
Index: wparser_def.c
===
RCS file: /a/pgsql/dev/anoncvs/pgsql/src/backend/tsearch/wparser_def.c,v
retrieving revision 1.24
diff -c -r1.24 wparser_def.c
*** wparser_def.c 16 Jul 2009 06:33:44 - 1.24
--- wparser_def.c 23 Sep 2009 23:19:28 -
***
*** 1225,1230
--- 1225,1231
{p_isdigit, 0, A_NEXT, TPS_Null, 0, NULL},
{p_iseqC, '=', A_NEXT, TPS_Null, 0, NULL},
{p_iseqC, '-', A_NEXT, TPS_Null, 0, NULL},
+ {p_iseqC, '_', A_NEXT, TPS_Null, 0, NULL},
{p_iseqC, '#', A_NEXT, TPS_Null, 0, NULL},
{p_iseqC, '/', A_NEXT, TPS_Null, 0, NULL},
{p_iseqC, ':', A_NEXT, TPS_Null, 0, NULL},
--
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] Requesting the Revision History
nanda gopal escreveu: projects.It will be helpfull to me if you send me the revision history of PostgreSQL.So please kindly send me the revision history(consisting of features changed). This is not a bug. Please don't post unrelated topics here. You can rsync our anonymous repository. rsync -qavzCH --delete anoncvs.postgresql.org::pgsql-cvs /tmp/pgcvs/ You can also browse it. http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/ -- Euler Taveira de Oliveira http://www.timbira.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] fillfactor hides autovacuum parameters in 8.4.0
Itagaki Takahiro escreveu: In 8.4.0, we create StdRdOptions if a relation has some fields in pg_class.reloption. Then, unspecified fields are filled with the default values. The values are always hard-coded default values and don't reflect current GUC settings. Hey, how I couldn't notice that. :( To fix the bug, each field in StdRdOptions should have not-specified flag. If not specified, autovacuum should use current GUC settings instead of reloptions. Is it possible to change the default values of reloptions to some magic number (-1 or so) ? BTW, we agreed that magic numbers is a hack in pg_autovacuum and we wouldn't use it in reloptions [1]. There might be another idea that we fill StdRdOptions with current GUC settings instead of hard-coded default values. It looks cleaner, but we need to treat dynamic default values and invalidate reloptions if we reload settings. +1. I'm afraid we need to touch too much code for a fix. Let's do it for 8.5. I'll try to come up with a patch. A not-so-invasive code is to transform all AutoVacOpts elements in pointers and to leave the default assignment to relation_needs_vacanalyze(). If nobody steps up I'll give it a stab later. [1] http://archives.postgresql.org/pgsql-hackers/2009-02/msg00303.php -- Euler Taveira de Oliveira http://www.timbira.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 #4927: psql does spoil the query before sending it to server
handling numeric literals with dots in psql copy command escreveu:
fi...@filip=# \copy ( select 1.23::numeric as num ) to 'out.csv' with csv
header
ERROR: syntax error at or near .
LINE 1: COPY ( select 1 . 23::numeric as num ) TO STDOUT CSV HEADER
^
\copy: ERROR: syntax error at or near .
LINE 1: COPY ( select 1 . 23::numeric as num ) TO STDOUT CSV HEADER
^
query inside parentheses is OK.
same bug reproduced in 8.3.7
Thanks for your report.
Why are we analysing the query there? One possible fix is to remove the '.' as
delimiter in strtokx(). The trivial patch is attached.
--
Euler Taveira de Oliveira
http://www.timbira.com/
Index: copy.c
===
RCS file: /a/pgsql/dev/anoncvs/pgsql/src/bin/psql/copy.c,v
retrieving revision 1.80
diff -c -r1.80 copy.c
*** copy.c 26 Apr 2009 15:31:50 - 1.80
--- copy.c 17 Jul 2009 19:41:58 -
***
*** 146,152
while (parens 0)
{
! token = strtokx(NULL, whitespace, .,(), \',
nonstd_backslash, true,
false, pset.encoding);
if (!token)
goto error;
--- 146,152
while (parens 0)
{
! token = strtokx(NULL, whitespace, ,(), \',
nonstd_backslash, true,
false, pset.encoding);
if (!token)
goto error;
--
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 #4927: psql does spoil the query before sending it to server
Tom Lane escreveu: Euler Taveira de Oliveira eu...@timbira.com writes: Why are we analysing the query there? One possible fix is to remove the '.' as delimiter in strtokx(). The trivial patch is attached. Surely that would break a lot of other cases. Why? Even if it can't catch all cases when we remove the '.', the query will be parsed (again) by PostgreSQL. -- Euler Taveira de Oliveira http://www.timbira.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 #4830: operator does not exists
Gilvan Garcelan escreveu: Eu tenho uma query que roda na versao 8.0 mas na 8.3 ocorre o seguinte erro. Você leu as notas de lançamento [1]? Algumas conversões implícitas foram removidas na 8.3. operator does not exists: integer ~~ unknow line 39: and (nome do campo Like '1' /*FilterParam1*/ Isto *não* é um bug. Utilize nome_do_campo like 1. Por que você está utilizando LIKE ao invés de um = ? PS da próxima vez escreva em inglês porque nem todos nesta lista falam português. [1] http://www.postgresql.org/docs/8.3/static/release-8-3.html#AEN86487 -- Euler Taveira de Oliveira http://www.timbira.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 #4827: install
Silvano de Souza escreveu: Failed to get System metrics for terminal services:87 8.1 is *not* supported on Windows platform anymore. Consider using the latest stable release which is 8.3.7. If you can't, at least you should be using the latest 8.1.X version (which is 8.1.17); have in mind that binary packages were only produced by PostgreSQL community until 8.1.11. -- Euler Taveira de Oliveira http://www.timbira.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] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Tom Lane escreveu: Peter Eisentraut pete...@gmx.net writes: On Friday 10 April 2009 22:50:02 Tom Lane wrote: I do not believe it --- there is a significant difference in the difficulty of passive listening and active spoofing. Sure, there is a difference. But what is it, and what percentage of users do you think are affected by it and can judge the difference? I don't know, and I don't wish to be forcing a decision about it on users. Why don't we follow Magnus suggestion? HINT: you could disable certificate verification by setting PGSSLVERIFY=none -- Euler Taveira de Oliveira http://www.timbira.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 #4755: lost graphical relationship between tables in DbVis w/ new PG release
Ellen Strnod escreveu: The foreign key constraint is in effect in the new db, if I test by adding a record with an invalid foreign key, so I suspect the information is coming from another attribute - some metadata perhaps? This is not a PostgreSQL bug. Blame DBVisualizer guys, not us. -- Euler Taveira de Oliveira http://www.timbira.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 #4749: trigonometric functions broken
Stefano Salvador escreveu: select sin(pi()); returns: 1.2246 euler=# select sin(pi()); sin -- 1.22460635382238e-16 ^ It works for me. You didn't pay attention at the precision. -- Euler Taveira de Oliveira http://www.timbira.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 #4718: select +'8:00'::interval; gives an error
Roman Kononov escreveu: This is not a bug, but a missing feature. test=# select +'8:00'::interval; ERROR: operator does not exist: + interval LINE 1: select +'8:00'::interval; ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. You can solve it using: euler=# select '+8:00'::interval; interval -- 08:00:00 (1 registro) euler=# select '-8:00'::interval; interval --- -08:00:00 (1 registro) As pointed by Tom in an ancient thread [1], I agree that we could add + and @ unary operator for interval datatype. Unfortunately, such a patch has not been proposed yet. [1] http://archives.postgresql.org//pgsql-general/2003-09/msg00292.php -- Euler Taveira de Oliveira http://www.timbira.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 #4658: copy problem
Brundle Fly escreveu: This is ok in ubuntu, but in centos doesnt work?. COPY query TO is only available in = 8.2. Are you sure CentOS is using a 8.3 version too? If so, what is the error message? -- Euler Taveira de Oliveira http://www.timbira.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 #4632: Duplicate
Juan Moreno escreveu: I have a problem for certain tables. When mysql executes pg_query(), then it duplicates the insertion, or sometimes 3,4 times. But it is not a constant issue and with all the tables Witout a test case, it is hard to say something about it. It could be a trigger function, for example. Also, do you regularly vacuum those tables? -- Euler Taveira de Oliveira http://www.timbira.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 #4402: Column expansion: date comes wthout a cast
Joachim Unger escreveu:
The column expansion lists date types without a date cast.
And all of the text types too.
Here is an example where I'm using NEW inside a trigger:
[...]
ins_sql := 'INSERT INTO ' || quote_ident(new_child_table) || '('
||col_names(new_child_table) || ') VALUES ' || NEW;
RAISE NOTICE 'INSERT: %',ins_sql;
EXECUTE ins_sql;
[...]
Why aren't you expanding it yourself? Currently, PostgreSQL doesn't have
a function that does the quoting-if-needed automagically.
--
Euler Taveira de Oliveira
http://www.timbira.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 #4370: connectby method
Derek Bob escreveu: I've got a question about table connectby method. Say, we have five elements which are 1,2,3,4,5. Each of them are the roots in the tree.Instead of using five connectby methods to generate them all in the table, I assume there is a element 0, which is the parent of them, in the tree(which is not existed in the real table). So only one connectby is enough to get them all, and it works. This is *not* a bug. How would connectby guess you want to group all of the root elements? Maybe another connectby variant that assumes start_with as an array. A patch would be welcome. -- Euler Taveira de Oliveira http://www.timbira.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] Postgresql v8.3.3 + Perl v5.10
[EMAIL PROTECTED] escreveu: Bug in that, that I install PG on server with perl 5.10 installed, but PG fails to run any PLPERL code How to fix? Could you post some test case? -- Euler Taveira de Oliveira http://www.timbira.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 #4186: set lc_messages does not work
Thomas H wrote: the patch discussed here [1] that supposedly made the win32 msvc builds use lc_locale properly has flaws. I think you misunderstood the feature [1] added recently. This new feature doesn't rely on lc_messages to localize the day and month names; it uses lc_time. Look at the archives for reference. [1] http://archives.postgresql.org/pgsql-patches/2008-04/msg00451.php -- Euler Taveira de Oliveira http://www.timbira.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 #4186: set lc_messages does not work
Thomas H. wrote: please observe the (previously already submitted) test queries. i've removed the date/time testqueries to no further distract from the problem. the bogus query select x; always results in a german error messages no matter what LC_MESSAGES is set: OK, that's another problem. AFAIK, that's a known problem because Windows doesn't have LC_MESSAGES. The above comment (pg_locale.c) suggests that there is no verification for the locale that is been set. A possible solution is to use IsValidLocaleName() [1] or LocaleNameToLCID() [2] but it seems that they're only available for Vista. :( Maybe we could emulate one of these functions with a mapping table [3]. [searching ...] It seems there are problems with LCIDs; they don't describe the locales acurately. pgwin hackers? Could you try to use one of the locale names described in [4]? /* * LC_MESSAGES category does not exist everywhere, but accept it anyway * * On Windows, we can't even check the value, so the non-doit case is a * no-op */ [1] http://msdn.microsoft.com/en-us/library/ms776379(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/ms776388(VS.85).aspx [3] http://msdn.microsoft.com/en-us/library/ms776260.aspx -- Euler Taveira de Oliveira http://www.timbira.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 #4101: Fails to start when transaction log on another drive
Mikel Lindsaar wrote: linkd d:\PostgreSQL\8.3\data\pg_xlog C:\Program Files\PostgreSQL\transaction_log\pg_xlog The correct xlog path is $PGDATA\pg_xlog. Normally, it is 'C:\Program Files\PostgreSQL\X.X\data\pg_xlog'. -- Euler Taveira de Oliveira http://www.timbira.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] FOR-IN-EXECUTE: FOR does not replanned on each entry to the FOR loop
[EMAIL PROTECTED] wrote: FOR and WHILE results differ WHILE returns two rows but FOR returns only one. and it seems that FOR does not replanned on each entry to the FOR loop While docs says: 38.6.4. Looping Through Query Results This is like the previous form, except that the source query is specified as a string expression, which is evaluated and replanned on each entry to the FOR loop You are confusing things. The statement above talks about FOR rec IN EXECUTE query_string LOOP ... END LOOP. There is no WHILE. When you're using WHILE, the EXECUTE is actually evaluated inside the loop and not in the loop condition (that's why you're seeing another iteration). -- Euler Taveira de Oliveira http://www.timbira.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] Redundant explicit field name/types description while select from function with return type of record
[EMAIL PROTECTED] wrote: a column definition list is required for functions returning record It seems a BUG I don't think so. We can say it is a missing feature. As stated in [1], record types don't have a predefined structure -- they're placeholders. How do you know the row structure before hand? Its structure can be changed on-the-fly. Are you agree with my suggestion? If so will you plan to fix this BUG? TODO? [1] http://www.postgresql.org/docs/8.3/static/plpgsql-declarations.html#PLPGSQL-DECLARATION-RECORDS -- Euler Taveira de Oliveira http://www.timbira.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] ecpg produces code that won't compile
Steve Clark wrote: ecpg_test.pgc:36: error: invalid application of `sizeof' to incomplete type `varchar_h_tunnel_active' It seems that are you using implicit cast from varchar to inet. It doesn't work in 8.3 anymore. You need to cast before calling the function, ie, func(col::inet). euler=# select '127.0.0.1/32'::varchar = '127.0.0.1/32'::inet; ERROR: operator does not exist: character varying = inet LINHA 1: select '127.0.0.1/32'::varchar = '127.0.0.1/32'::inet; ^ DICA: No operator matches the given name and argument type(s). You might need to add explicit type casts. euler=# select '127.0.0.1/32'::varchar::inet = '127.0.0.1/32'::inet; ?column? -- t (1 registro) -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] help me plz with 2 postgres users
[EMAIL PROTECTED] wrote: How can I delete first postgres user. Ugh. How did you duplicate if there is an unique index in rolname ? pg_shadow is a view; you want to take a look at the real relation pg_authid. delete from pg_authid where ctid = '(0,1)' -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3986: Error ts_vector with UTF8 WS2003
Yann wrote: When i try to execute the ts_vector function with a text i get the following error : ERROR: 22021: invalid byte sequence for encoding UTF8: 0xc3 It seems to be a client encoding problem. What is your client_encoding? A common problem is a mismatch between client_encoding and the terminal or application encoding. -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit
Edwin Groothuis wrote: Ouch. But... since very long words are already not indexed (is the length configurable anywhere because I don't mind setting it to 50 characters), I don't think that it should bomb out of this but print a similar warning like String only partly indexed. This is not a bug. I would say it's a limitation. Look at src/include/tsearch/ts_type.h. You could decrease len in WordEntry to 9 (512 characters) and increase pos to 22 (4 Mb). Don't forget to update MAXSTRLEN and MAXSTRPOS accordingly. I'm still trying to determine how big the message it failed on was... Maybe we should change the string is too long for tsvector to string is too long (%ld bytes, max %ld bytes) for tsvector. -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3891: Multiple UPDATE doesn't handle UNIQUE constraint correctly
Adriaan van Os wrote: This will cause a UNIQUE violation in de middle of the UPDATE statement, although after completion of the statement there is no such violation. This is not a bug. Although deferred constraints are not yet implemented for Postgres, the docs at http://www.postgresql.org/docs/8.2/static/sql-set-constraints.html state: But I forgot to read this: Check and unique constraints are always effectively not deferrable. It's a known problem (TODO item). See Greg's elegant solution [1]. [1] http://people.planetpostgresql.org/greg/index.php?/archives/2006/06/10.html -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] unable to see other schemas besides public
Gabriel Ramirez wrote: so seems if one don't specified the schemaname.objects to list the database don't return them, or maybe I'm missing a step after creating the schema and objects to be able to list them. This is not a bug. You need to set your schema in the search_path [1]. [1] http://www.postgresql.org/docs/8.3/static/ddl-schemas.html#DDL-SCHEMAS-PATH -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #3734: Invalid XML schema output.
Bruce Momjian wrote:
Agreed. Feel free to add whitespace before every / of simple xml elements.
Uh, was this done?
Nope. Attached is a patch that does it. I'm attaching another cosmetic
patch that replaces the use of some single quotes with double quotes in
the XML attributes output.
--
Euler Taveira de Oliveira
http://www.timbira.com/
*** ./src/backend/utils/adt/xml.c.orig 2007-11-23 01:55:00.0 -0200
--- ./src/backend/utils/adt/xml.c 2007-11-23 02:01:24.0 -0200
***
*** 2641,2658
appendStringInfo(result,
xsd:complexType name=\%s\\n
xsd:sequence\n
! xsd:element name=\row\ type=\%s\ minOccurs=\0\ maxOccurs=\unbounded\/\n
/xsd:sequence\n
/xsd:complexType\n\n,
tabletypename, rowtypename);
appendStringInfo(result,
! xsd:element name=\%s\ type=\%s\/\n\n,
xmltn, tabletypename);
}
else
appendStringInfo(result,
! xsd:element name=\%s\ type=\%s\/\n\n,
xmltn, rowtypename);
xsd_schema_element_end(result);
--- 2641,2658
appendStringInfo(result,
xsd:complexType name=\%s\\n
xsd:sequence\n
! xsd:element name=\row\ type=\%s\ minOccurs=\0\ maxOccurs=\unbounded\ /\n
/xsd:sequence\n
/xsd:complexType\n\n,
tabletypename, rowtypename);
appendStringInfo(result,
! xsd:element name=\%s\ type=\%s\ /\n\n,
xmltn, tabletypename);
}
else
appendStringInfo(result,
! xsd:element name=\%s\ type=\%s\ /\n\n,
xmltn, rowtypename);
xsd_schema_element_end(result);
***
*** 2709,2719
if (!tableforest)
appendStringInfo(result,
! xsd:element name=\%s\ type=\%s\/\n,
xmltn, tabletypename);
else
appendStringInfo(result,
! xsd:element name=\%s\ type=\%s\ minOccurs=\0\ maxOccurs=\unbounded\/\n,
xmltn, tabletypename);
}
--- 2709,2719
if (!tableforest)
appendStringInfo(result,
! xsd:element name=\%s\ type=\%s\ /\n,
xmltn, tabletypename);
else
appendStringInfo(result,
! xsd:element name=\%s\ type=\%s\ minOccurs=\0\ maxOccurs=\unbounded\ /\n,
xmltn, tabletypename);
}
***
*** 2727,2733
/xsd:complexType\n\n);
appendStringInfo(result,
! xsd:element name=\%s\ type=\%s\/\n\n,
xmlsn, schematypename);
return result.data;
--- 2727,2733
/xsd:complexType\n\n);
appendStringInfo(result,
! xsd:element name=\%s\ type=\%s\ /\n\n,
xmlsn, schematypename);
return result.data;
***
*** 2775,2781
NULL);
appendStringInfo(result,
! xsd:element name=\%s\ type=\%s\/\n,
xmlsn, schematypename);
}
--- 2775,2781
NULL);
appendStringInfo(result,
! xsd:element name=\%s\ type=\%s\ /\n,
xmlsn, schematypename);
}
***
*** 2785,2791
/xsd:complexType\n\n);
appendStringInfo(result,
! xsd:element name=\%s\ type=\%s\/\n\n,
xmlcn, catalogtypename);
return result.data;
--- 2785,2791
/xsd:complexType\n\n);
appendStringInfo(result,
! xsd:element name=\%s\ type=\%s\ /\n\n,
xmlcn, catalogtypename);
return result.data;
***
*** 2969,2975
appendStringInfo(result,
xsd:complexType mixed=\true\\n
xsd:sequence\n
! xsd:any name=\element\ minOccurs=\0\ maxOccurs=\unbounded\ processContents=\skip\/\n
/xsd:sequence\n
/xsd:complexType\n);
}
--- 2969,2975
appendStringInfo(result,
xsd:complexType mixed=\true\\n
xsd:sequence\n
! xsd:any name=\element\ minOccurs=\0\ maxOccurs=\unbounded\ processContents=\skip\ /\n
/xsd:sequence\n
/xsd:complexType\n);
}
***
*** 2986,2992
if (typmod != -1)
appendStringInfo(result,
xsd:restriction base=\xsd:string\\n
! xsd:maxLength value=\%d\/\n
/xsd:restriction\n,
typmod - VARHDRSZ);
break;
--- 2986,2992
if (typmod != -1)
appendStringInfo(result,
xsd:restriction base=\xsd:string\\n
! xsd:maxLength value=\%d\ /\n
/xsd:restriction\n,
typmod - VARHDRSZ);
break;
***
*** 3001,3008
if (typmod != -1)
appendStringInfo(result,
xsd:restriction base=\xsd:decimal\\n
! xsd:totalDigits value=\%d\/\n
! xsd:fractionDigits value=\%d\/\n
/xsd:restriction\n,
((typmod - VARHDRSZ) 16) 0x,
(typmod - VARHDRSZ) 0x);
--- 3001,3008
if (typmod != -1)
appendStringInfo(result,
xsd:restriction base
Re: [BUGS] BUG #3734: Invalid XML schema output.
Peter Eisentraut wrote: Having a space before / appears to be common practice, including in the examples in the SQL/XML spec. Agreed. Feel free to add whitespace before every / of simple xml elements. -- Euler Taveira de Oliveira http://www.timbira.com/ ---(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
Re: [BUGS] BUG #3734: Invalid XML schema output.
Ben Leslie wrote: The specific problem is that the following is malformed; the xsd:restriction tag is never closed. xsd:simpleType name=Domain.test.public.isoweek xsd:restriction base=DATE /xsd:simpleType Exact. Per 9.11 (6, b, iv) or 9.15 (8, m, vi), it's a simple element. The attached patch should fix it. I'm attaching another small patch to strip some space and be consistent with other xml tags. -- Euler Taveira de Oliveira http://www.timbira.com/ *** src/backend/utils/adt/xml.c.orig 2007-11-09 16:33:56.0 -0200 --- src/backend/utils/adt/xml.c 2007-11-09 16:37:30.0 -0200 *** *** 2987,2993 base_typeoid = getBaseTypeAndTypmod(typeoid, base_typmod); appendStringInfo(result, ! xsd:restriction base=\%s\\n, map_sql_type_to_xml_name(base_typeoid, base_typmod)); } } --- 2987,2993 base_typeoid = getBaseTypeAndTypmod(typeoid, base_typmod); appendStringInfo(result, ! xsd:restriction base=\%s\/\n, map_sql_type_to_xml_name(base_typeoid, base_typmod)); } } *** src/backend/utils/adt/xml.c.orig 2007-11-09 16:33:56.0 -0200 --- src/backend/utils/adt/xml.c 2007-11-09 17:01:50.0 -0200 *** *** 2595,2605 if (!tableforest) appendStringInfo(result, ! xsd:element name=\%s\ type=\%s\ /\n, xmltn, tabletypename); else appendStringInfo(result, ! xsd:element name=\%s\ type=\%s\ minOccurs=\0\ maxOccurs=\unbounded\ /\n, xmltn, tabletypename); } --- 2595,2605 if (!tableforest) appendStringInfo(result, ! xsd:element name=\%s\ type=\%s\/\n, xmltn, tabletypename); else appendStringInfo(result, ! xsd:element name=\%s\ type=\%s\ minOccurs=\0\ maxOccurs=\unbounded\/\n, xmltn, tabletypename); } *** *** 2656,2662 NULL); appendStringInfo(result, ! xsd:element name=\%s\ type=\%s\ /\n, xmlsn, schematypename); } --- 2656,2662 NULL); appendStringInfo(result, ! xsd:element name=\%s\ type=\%s\/\n, xmlsn, schematypename); } ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] Provide a way to not ask for a password in psql
Martin Pitt wrote: For example, psql -l is a convenient method to check whether the postmaster is running at all, finished with startup and ready for connections. Why not just pg_ctl status? -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] reindexdb in Windows
Hi, reindexdb.exe is not installed with PostgreSQL in Windows. Is it intentional or a bug? -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #3323: Wrong charset for the lower and upper functions
Eduardo Santos wrote: When you have the latin character ç and use the lower or the upper function, instead of return the approprite character, it returns the oposite one, so the comparisons in the whole DB are wrong. If you have a word such as Serviço, and you use the lower function, the result is serviÇo, instead of serviço. the other side is also true: if you use upper in the same eord, the result is SERVIçO, instead of SERVIÇO. Did you read [1] for issues with code page on Windows console windows? What kind of encoding are you using? I haven't reproduce your problem here. [1] http://www.postgresql.org/docs/8.2/static/app-psql.html -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] pg_stat_activity feature or bug?
Hi, The user in pg_stat_activity does not change when use the 'set session authorization' command. So we couldn't track the real user. Is it a bug or a feature? regression=# select usesysid,usename,datname from pg_stat_activity; usesysid | usename | datname --+--+ 10 | postgres | regression (1 registro) regression=# set session authorization timbira; SET regression= select usesysid,usename,datname from pg_stat_activity; usesysid | usename | datname --+--+ 10 | postgres | regression (1 registro) regression= -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #2870: incorrect man page for postgres
Dmitry D. Khlebnikov wrote: The man page for postgres(1) has a wrong description of the '-S' option. Previously, the '-S' option means that postgres will start in the 'silent' mode, but in version 8.2 the '-S' option describes the amount of memory for sorts. I think you change the order, in 8.1 -S option describes the amount of memory but in 8.2 it describes the silent mode. This is because there was some mismatch options in postgres and postmaster. See Make command-line options of postmaster and postgres identical (Peter) in release notes [1]. [1] http://www.postgresql.org/docs/8.2/static/release-8-2.html -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] wrong behavior using to_char()
Hi, I notice a strange behavior using to_char() function. I'm using locale pt_BR but it could happen with any locale. template1=# select to_char(12345.67, '999G999D999'); to_char -- 12,345,670 (1 registro) In the pt_BR locale, the thousand separator is . So it should return 12345,670. Looking at the source, I saw that the test cases for locale properties are independent among them. I think that the correct form is to have all-or-nothing test case or didn't test *lconv-property ( is evaluated to false). Attached is a patch that fixes it using the second option. -- Euler Taveira de Oliveira http://www.timbira.com/ x Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] wrong behavior using to_char()
Jorge Godoy wrote: In the pt_BR locale, the thousand separator is . So it should return The thousands separator in pt_BR is .. Oh, good catch. There is so much hack in my glibc. :-) -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] stopping server does not remove external_pid_file
Tom Lane wrote: No, because the external pidfile has zero to do with Postgres' internal behavior. +1. So we have two options: have external_pid_file mimics the internal behavior or deprecates it. I couldn't find the discussion about it; just the patch [1]. IIRC this 'feature' was proposed to permit another home to postmaster.pid file. Am I wrong? But seems to duplicate the pid file information. [1] http://archives.postgresql.org/pgsql-patches/2004-06/msg6.php -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] stopping server does not remove external_pid_file
Martin Pitt wrote: I just played around with external_pid_file in 8.1.4. I noticed that the file is created and filled properly, but it is not removed again when the server is stopped. Looking at the code I see this comment in src/backend/postmaster/postmaster.c /* Should we remove the pid file on postmaster exit? */ IMHO, yes. It's not useful anymore. Maybe some simple test in pmdie(). I'm too tired to code something now. :( -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] reindexdb command utlility
Henrik Zagerholm wrote: You can always ignore NOTICE. grep is your friend. :-) True, but usually I like to have my ERROR messages to stderr and INFO to stdout. But it's not true in PostgreSQL. All ereport() messages are sent to stderr. In some scripts, the -e (echo) is used to print command to stdout. Like I said, you need to | grep -v your stderr output. -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] reindexdb command utlility
I used wanted to point out the the ( -q, --quiet ) parameter for reindexdb command utility does not work. Actually it is *not* a bug. The NOTICE is printed by the REINDEX command; reindexdb is just a wrapper around REINDEX command. If you set up 'client_min_messages' in postgresql.conf, you don't get those 'annoying' messages. Also reindexdb writes NOTICE to standard err for every table it reindexes which makes it really hard to use in script as it always produces an errror. :-) You can always ignore NOTICE. grep is your friend. :-) Looking at the code, IMHO we could raise the ereport from NOTICE to INFO (see the patch attached). None of the scripts actually raise NOTICEs if it succeeds. Comments? -- Euler Taveira de Oliveira http://www.timbira.com/ Index: src/backend/commands/indexcmds.c === RCS file: /projects/cvsroot/pgsql/src/backend/commands/indexcmds.c,v retrieving revision 1.139 diff -c -r1.139 indexcmds.c *** src/backend/commands/indexcmds.c10 May 2006 23:18:39 - 1.139 --- src/backend/commands/indexcmds.c31 May 2006 01:28:49 - *** *** 1108,1114 /* functions in indexes may want a snapshot set */ ActiveSnapshot = CopySnapshot(GetTransactionSnapshot()); if (reindex_relation(relid, true)) ! ereport(NOTICE, (errmsg(table \%s\ was reindexed, get_rel_name(relid; CommitTransactionCommand(); --- 1108,1114 /* functions in indexes may want a snapshot set */ ActiveSnapshot = CopySnapshot(GetTransactionSnapshot()); if (reindex_relation(relid, true)) ! ereport(INFO, (errmsg(table \%s\ was reindexed, get_rel_name(relid; CommitTransactionCommand(); ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2456: How to write user defined functions in Postgress sql
Vivekananda wrote: I have good knowledge in Oracle-Pl/sql.But,now my client wants to use PGSQL.Now i am sending function as below. This is *not* a bug. Consider posting in the correct list pgsql-general. -- Euler Taveira de Oliveira http://www.timbira.com/ ---(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
Re: [BUGS] syntax error
Roberto Castro wrote: Numa aplicação, de acordo com o btnbotton clicado, a variável ‘opçao’ receberá um valor. No decorrer do processo, de acordo com a ‘opcao’ deverá executar um comando da function onde os valores a serem adicionados (input) serão supridos na aplicação. Envie somente *bugs* para esta lista. Por favor envie o seu problema para brasil-usuarios@pgfoundry.org (lista em português) ou [EMAIL PROTECTED] (lista em inglês). Report only *bugs* to this list. Please report your problem to brasil-usuarios@pgfoundry.org (brazilian list) or [EMAIL PROTECTED] (english list). -- Euler Taveira de Oliveira ---(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
Re: NLS vs error processing, again (was Re: [BUGS] Composite Type
Tom Lane wrote: It seems to me that there basically is no graceful solution to this sort of mismatch. It might be possible to kluge things so that we disable NLS once we've recursed too many times in error processing, but that's surely pretty ugly. What would be a lot more user-friendly would be to refuse the attempt to set client_encoding to something that can't handle our error message encoding, but I don't know what a reasonable set of restrictions would be. Maybe it's the time to convert all PO files to UTF-8. I'm in process to convert pt_BR ones. -- Euler Taveira de Oliveira ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2166: attempted to update invisible tuple
--- Tom Lane [EMAIL PROTECTED] escreveu: Euler Taveira de Oliveira [EMAIL PROTECTED] writes: I just execute the same transaction in 2 different backends and I got the message: 'attempted to update invisible tuple'. If you want this investigated then you'll need to provide a self-contained example. We have other things to do than guess about the contents of your database... Sorry for that. I didn't have the data yet. Some data to test it is in: http://www.timbira.com/tst2.sql.gz In 8.0 and previous I didn't reproduce it. Is it something related to UPDATE ... FROM patch that I submitted? I just execute the same transaction in 2 different backends and I got the message: 'attempted to update invisible tuple'. In the first transaction I execute: BEGIN - UPDATE and then open the other transaction and execute: BEGIN - UPDATE so I commit the first one and got that message. == first transaction = tst=# begin; BEGIN tst=# update produtos set estoque = estoque - itensmov.qtde from itensmov where trim(itensmov.codigo) = 'C0001' and itensmov.fk_produto = produtos.id_produto and produtos.controlarestoque = 'S'; UPDATE 21 tst=# commit; COMMIT tst=# == first transaction = == second transaction tst=# begin; BEGIN tst=# update produtos set estoque = estoque - itensmov.qtde from itensmov where trim(itensmov.codigo) = 'C0003' and itensmov.fk_produto = produtos.id_produto and produtos.controlarestoque = 'S'; ERRO: attempted to update invisible tuple tst=# == second transaction Euler Taveira de Oliveira euler[at]yahoo_com_br ___ Yahoo! doce lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html ---(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 #2166: attempted to update invisible tuple
The following bug has been logged online: Bug reference: 2166 Logged by: Euler Taveira de Oliveira Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1+ Operating system: Slackware 10.1 Description:attempted to update invisible tuple Details: I just execute the same transaction in 2 different backends and I got the message: 'attempted to update invisible tuple'. In the first transaction I execute: BEGIN - UPDATE and then open the other transaction and execute: BEGIN - UPDATE so I commit the first one. In 8.0 it executes fine. == first transaction = tst=# begin; BEGIN tst=# update produtos set estoque = estoque - itensmov.qtde from itensmov where trim(itensmov.codigo) = 'C0001' and itensmov.fk_produto = produtos.id_produto and produtos.controlarestoque = 'S'; UPDATE 21 tst=# commit; COMMIT tst=# == first transaction = == second transaction tst=# begin; BEGIN tst=# update produtos set estoque = estoque - itensmov.qtde from itensmov where trim(itensmov.codigo) = 'C0003' and itensmov.fk_produto = produtos.id_produto and produtos.controlarestoque = 'S'; ERRO: attempted to update invisible tuple tst=# == second transaction ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2077: Hiding databases which I am not owner
--- Martin Pelikan [EMAIL PROTECTED] escreveu: I think it's a bug because of security - nosey people are everywhere... No. It's a feature. And I want not to other people see how many users and databases are here - server is half-public :) See is one thing, access is another thing. We never hid databases and other catalog objects. Instead we allow and deny access to this databases. See pg_hba.conf documentation for information. Euler Taveira de Oliveira euler[at]yahoo_com_br ___ Yahoo! doce lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1662: Table constrains are not properly inherited.
Hi Steven, Description:Table constrains are not properly inherited. Have you read the section 5.5 in the manual? http://developer.postgresql.org/docs/postgres/ddl-inherit.html A serious limitation of the inheritance feature is that indexes (including unique constraints) and foreign key constraints only apply to single tables, not to their inheritance children. Euler Taveira de Oliveira euler[at]yahoo_com_br Yahoo! Mail, cada vez melhor: agora com 1GB de espaço grátis! http://mail.yahoo.com.br ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
