[BUGS] BUG #5636: extra ( or missing )
The following bug has been logged online: Bug reference: 5636 Logged by: KOIZUMI Satoru Email address: koizumi...@minos.ocn.ne.jp PostgreSQL version: 9.0RC1 Operating system: MacOS X Description:extra ( or missing ) Details: At 33.8.5. The decimal type of PostgreSQL 9.0RC1 Documentation, ( is before by means. But there is no ). | the decimal type can be created either on the stack | or on the heap (by means of the functions | PGTYPESdecimal_new() and PGTYPESdecimal_free(). Maybe ( is not needed or ) is needed after PGTYPESdecimal_free(). -- 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 #5637: JDBC driver method setClob always uses getAsciiStream()
The following bug has been logged online:
Bug reference: 5637
Logged by: Jochen Terstiege
Email address: jochen.tersti...@quinscape.de
PostgreSQL version: 8.4
Operating system: Windows XP SP3
Description:JDBC driver method setClob always uses getAsciiStream()
Details:
Using driver: postgresql-8.4-701.jdbc3.jar
The method setClob() in the AbstractJdbc2Statement calls the method
getAsciiStream() on the provided Clob.
This leads to problems if the given Clob contains an UTF-8 encoded string.
Should the driver call getCharacterStream() instead? Can this problem be
solved in a different way?
Relevant code from the class:
public void setClob(int i, Clob x) throws SQLException
{
checkClosed();
if (x == null)
{
setNull(i, Types.CLOB);
return;
}
InputStream l_inStream = x.getAsciiStream();
...
--
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 #5638: disagreement of argument name
The following bug has been logged online: Bug reference: 5638 Logged by: KOIZUMI Satoru Email address: koizumi...@minos.ocn.ne.jp PostgreSQL version: 9.0RC1 Operating system: MacOS X Description:disagreement of argument name Details: At 33.10.4. Additional functions of PostgreSQL 9.0rc1 Documentation, the third argument of the function dtcvfmtasc is dtvalue. But in its following description, the argument name is referred as ts. -- 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] issue about information_schema REFERENTIAL_CONSTRAINTS
On tor, 2010-09-02 at 07:54 +0200, Fabien COELHO wrote: We cannot change it. Yes we can! It, it is 100% postgresql: \d information_schema.referential_constraints View information_schema.referential_constraints ... FROM pg_namespace ncon JOIN pg_constraint con ON ncon.oid = con.connamespace JOIN pg_class c ON con.conrelid = c.oid Well, for the sake of argument, how would you propose to change it? -- 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 #5636: extra ( or missing )
KOIZUMI Satoru koizumi...@minos.ocn.ne.jp writes: At 33.8.5. The decimal type of PostgreSQL 9.0RC1 Documentation, ( is before by means. But there is no ). | the decimal type can be created either on the stack | or on the heap (by means of the functions | PGTYPESdecimal_new() and PGTYPESdecimal_free(). Fixed. It seemed to me the best way was to remove the ()'s from the function names, since that style is used elsewhere, eg in the description of ecpg's numeric type. 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
Re: [BUGS] BUG #5638: disagreement of argument name
KOIZUMI Satoru koizumi...@minos.ocn.ne.jp writes: At 33.10.4. Additional functions of PostgreSQL 9.0rc1 Documentation, the third argument of the function dtcvfmtasc is dtvalue. But in its following description, the argument name is referred as ts. Fixed, thanks. 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 #5639: Compile fails on heap
The following bug has been logged online: Bug reference: 5639 Logged by: Markus Ullmann Email address: m...@markus-ullmann.de PostgreSQL version: 9.0beta4 Operating system: Mac OS X 10.6.4 Description:Compile fails on heap Details: The compilation fails when trying to build fat binarys (aka 32bit and 64bit in one file). Patch to fix it: http://www.markus-ullmann.de/dokumente/postgres90beta_int64.patch -- 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 #5639: Compile fails on heap
Markus Ullmann m...@markus-ullmann.de writes: The compilation fails when trying to build fat binarys (aka 32bit and 64bit in one file). There are ways to do that, but it's substantially more complicated than the patch you propose (which doesn't even begin to work, since it's trying to patch a configure-generated file). Please see the PG archives for previous discussions of building universal binaries, eg the thread starting here: http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php 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
Re: [BUGS] issue about information_schema REFERENTIAL_CONSTRAINTS
Hallo, \d information_schema.referential_constraints View information_schema.referential_constraints ... FROM pg_namespace ncon JOIN pg_constraint con ON ncon.oid = con.connamespace JOIN pg_class c ON con.conrelid = c.oid Well, for the sake of argument, how would you propose to change it? For the sake of argument: For the information_schema to be useful, expected keys foreign keys must work properly so that the constraints can be joined meaningfully (otherwise, what is the point?). So any change would have to be be consistent over all definitions. The standard expects the triplet catalog,schema,constraint to be unique, but in Pg, catalog,schema,table,constraint is unique (I think). Too late to change that, obviously. So that let building a unique constraint name just for the information_schema, which is fine with me. (1) use the OID as the constraint name everywhere, it would work, it would not look so good for display, but it is simple and fast. (2) otherwise something built on top of table,constraint. To be on the safe side, I would build a string (sql_identifier?) with something like: quote_ident(table name) || '.' || quote_ident(constraint name) And the display would be reasonnable, like : TableName.$1 instead of a big bunch of $1. The affected information_schema views would be, as far as I can see: - check_constraint_routine_usage - check_constraints - constraint_column_usage - constraint_table_usage - domain_constraints - key_column_usage - referential_constraints - table_constraints With one or two affected columns each. Note that there may be the same issue with 'triggers' which are also identified by a catalog,schema,trigger triplet. Maybe others. I can send a patch on the information_schema definition in the coming days if someone feel that this may deserve a test. Otherwise, ISTM that it is a bug to be recorded somewhere. Have a nice day, -- Fabien. -- 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] issue about information_schema REFERENTIAL_CONSTRAINTS
Fabien COELHO coe...@cri.ensmp.fr writes: (1) use the OID as the constraint name everywhere, it would work, it would not look so good for display, but it is simple and fast. (2) otherwise something built on top of table,constraint. To be on the safe side, I would build a string (sql_identifier?) with something like: quote_ident(table name) || '.' || quote_ident(constraint name) Note that (2) fails for long names; you have to do something to compress to NAMEDATALEN. The big problem with either of these is that it's no longer easily possible to extract the actual constraint name from the view. In any case, I am fairly sure that not having the constraint_name column show the actual constraint name is a violation of the spirit of the SQL spec, whether or not you can claim that it meets the letter. 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
Re: [BUGS] BUG #5629: ALTER SEQUENCE foo START execute a RESTART
What about the risk of using ALTER SEQUENCE ... START N in a mixed environment? In the 8.4.x servers it will work as designed but in the 8.3.x (and below) servers, instead of issuing an error it will CORRUPT the sequence value without notice. I understand the point of keeping a (mis)feature when it's harmless or at least not amibiguous, but this is not the case here. While the 8.4 behavior -- the correct one -- is a mere configuration of little consequence, the 8.3 (and below) behavior is an unexpected RESET. I think it's safer to require the people that was using old versions with the wrong spell to fix their code than put lots of users of the current version in risk of using a potentially disastrous command -- when executed in previous versions. Should all 8.4.x (and beyond) users be forced to check server version before issuing this command? 2010/9/1 Alvaro Herrera alvhe...@commandprompt.com Excerpts from Euler Taveira de Oliveira's message of mié sep 01 10:18:10 -0400 2010: 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? That risks removing a (mis)feature that people are currently depending on. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Atenciosamente, Alexsander da Rosa Linux User #113925 Extremismo na defesa da liberdade não é defeito. Moderação na busca por justiça não é virtude. -- Barry Goldwater
[BUGS] BUG #5640: ODBC driver installed but not found
The following bug has been logged online: Bug reference: 5640 Logged by: Hannu Pohjanpalo Email address: hannu.pohjanp...@winware.fi PostgreSQL version: 8.4.4 Operating system: Windows 7 Pro 64 bit Description:ODBC driver installed but not found Details: I installed PostgreSQL 8.4.4 in my Windows 7 Professional (64 bit), and ran (as Administrator)Application Stack Builder to download and install the ODBC driver. This installation looked perfectly successful, but when starting Control Panel / Administrative Tasks / ODBC Settings, and press Add..., I cannot find this PostgreSQL ODBC driver, I can only see two SQLServer drivers. I uninstalled and tried again: same result. Have you seen this before? All ideas are welcome, thanks! -- 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 #5641: Can not create any python language
The following bug has been logged online: Bug reference: 5641 Logged by: Ron Park Email address: rpar...@gmail.com PostgreSQL version: 9.0 Operating system: Windows 7 professional 64 bit Description:Can not create any python language Details: when trying to create plpythonu ERROR: could not find function plpython_call_handler in file C:/Program Files/PostgreSQL/9.0/lib/plpython.dll when trying to create plpython2u or plpython3u I get ERROR: could not access file $libdir/plpython2: No such file or directory ERROR: could not access file $libdir/plpython3: No such file or directory I have python2.6, python3.1, python3.2 all installed (64 bit). All are in the path variable. used 9.0 MSI from enterprise to install postgresql 9.0 I have been running and using the 8.xx ones on windows 32 bit and ubuntu for 6 years and have been able to get python to behave well on both systems. But I am at a loss here.. Looks like there is a bug in the plpython.dll missing the call handler??? Not sure -- 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 #5640: ODBC driver installed but not found
On 3/09/2010 2:36 AM, Hannu Pohjanpalo wrote: I installed PostgreSQL 8.4.4 in my Windows 7 Professional (64 bit), and ran (as Administrator)Application Stack Builder to download and install the ODBC driver. This installation looked perfectly successful, but when starting Control Panel / Administrative Tasks / ODBC Settings, and press Add..., I cannot find this PostgreSQL ODBC driver, I can only see two SQLServer drivers. I uninstalled and tried again: same result. Have you seen this before? All ideas are welcome, thanks! You have to run the 32-bit ODBC administrator. PostgreSQL doesn't install a 64-bit ODBC driver yet, and anyway you'd need to configure the 32-bit one for access by any 32-bit apps. -- Craig Ringer Tech-related writing at http://soapyfrogs.blogspot.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
