[BUGS] BUG #4889: Accent Sensitive
The following bug has been logged online: Bug reference: 4889 Logged by: Ricardo Email address: rgc.t...@yahoo.com.br PostgreSQL version: 8.4 Operating system: All Description:Accent Sensitive Details: Need support for acent sensitive in UTF-8, in clause like SQL. Tks. -- 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 #2548: Fatal error with timezone
The following bug has been logged online: Bug reference: 2548 Logged by: Ricardo Solanilla Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: Windows XP Pro Description:Fatal error with timezone Details: my log show this error, the server stop and never more i could start it, and reinstall didn't work. (i lost all my databases) 2006-07-21 12:04:10 LOG: unrecognized time zone name: "America/Buenos_Aires" 2006-07-21 12:04:10 FATAL: invalid value for parameter "TimeZone": "America/Buenos_Aires" (no human touch the windows configuration or regional) ---(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] BUG #3970: ODBC Unknown Sizes Bug?
The following bug has been logged online: Bug reference: 3970 Logged by: Ricardo David Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 Operating system: Microsoft Windows XP SP2 (32bits) Description:ODBC Unknown Sizes Bug? Details: Until version psqlodbc-08_01_0200 the driver could work with Borland (Code Gear) products like Delphi. >From version psqlodbc-08_02_0100 up to psqlodbc-08_03_0100, when we mark: * Unknown Sizes = Don't Know; * Data Type Option = Text as LongVarChar, Unknowns as LongVarChar; all TEXT fields don't get recognized by the application as MEMO as they do before. We are still using the psqlodbc-08_01_0200 version with no problem. Thanks. ---(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] Troubles with JDBC method DataBaseMetaData.getTables()
Title: Message
Hi PostgreSQL developers,
I am
having trouble with PostgreSQL’s implementation of
DataBaseMetaData.getTables()
and looking at the code I found this comment and so I am writing to
you.
The
problem I am having is that If I create tables with
uppercase letters like this
create table
“FOO” ( “NUM” numeric
);
then I can´t use this code to check if the table
exists
ResultSet rs = conn.getMetaData().getTables( null, null, “FOO”, null
);
Boolean
exists = rs.next();
I suppose
it´s because the tableNamePattern is being converted toLowerCase()
// Added by Stefan Andreasen
<[EMAIL PROTECTED]>
// Now take the pattern into account
sql.append(") and relname like
'");
sql.append(tableNamePattern.toLowerCase());
sql.append("' order by relkind, relname");
I suggest
to eliminate this conversion and leave the user do the conversion if he
desires.
Greetings
Ricardo
Andrés Capurro
Senior
Software Developer
ATS
Advanced Technology Solutions S.A.
Av. Corrientes
880 Piso 11
(C1043AAV)
Buenos Aires
Argentina
Tel:
+54-11-6393-4345 +54-11-4393-4345
Fax:
+54-11-6393-4300
e-mail laboral:
mailto:[EMAIL PROTECTED]
e-mail
personal: mailto:[EMAIL PROTECTED]
web:
http://www.ats.com.ar
ICQ#: 103449056
[BUGS] Trouble
I am encountering seriuos problems when altering, creating tables and deleting records (zoombie process) with postgreSQL 7.3.3 and 7.3.2 I´ve seen that you´ve posted the new release of postgreSQL 7.3.4. Are all this issues solved ? If not, which release do you recommend ? best regards, RB
[BUGS] BUG #2210: an update query bug with a table but not with your backup
The following bug has been logged online: Bug reference: 2210 Logged by: Ricardo Solanilla Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: Windows XP Description:an update query bug with a table but not with your backup Details: i try those querys, they are too similars and simple.. but the first work fine but the second don't. Then i do a backup with insert clauses and put both tables in another empty database, but now work fine the second query too. it's depending on data i think, but i've done a backup and it have the same number of rows.. If you like to study that i can send you the entire backup of database. I'm system engenieer and hope i know that i know !! :-) Tia. update ctem set idctb = (SELECT CreConcep.DeudaIdctb from creconcep INNER JOIN CTEM C1 ON (c1.codcreconcep = creconcep.cod) WHERE C1.ID = CTEM.ID) where ctem.tipovalt = 'CC-M' and CodCreConcep is not null update ctem set idctb = (SELECT CreConcep.DeudaADevIdctb from creconcep INNER JOIN CTEM C1 ON (c1.codcreconcep = creconcep.cod) WHERE C1.ID = CTEM.ID) where ctem.tipovalt = 'CC-A' and CodCreConcep is not null ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #2219: bug in 12000 rows update
The following bug has been logged online: Bug reference: 2219 Logged by: Ricardo Solanilla Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: Windows XP Description:bug in 12000 rows update Details: i has report this bug earlier (ref. 2210) but i've news. The problem dissapear if i execute the update query with less rows .. begin transaction; ... where id > 100 and id <= 1000 commit; begin transaction; ... where id > 1001 .. and so commit; and i've noted that without begin transaction and commit the group of querys doesn't work (in pgadmin iii). the problem is in a specific database, then i only can offer send my database to anybody who like it, i cannot make a case to show the bug. ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #5966: extract(epoch..) function error
The following bug has been logged online:
Bug reference: 5966
Logged by: Ricardo Solanilla
Email address: i...@abaco-tandil.com.ar
PostgreSQL version: 8.3.0 b.1400
Operating system: windows nt
Description:extract(epoch..) function error
Details:
-- try this
select (extract(epoch from (date('2011-03-20'))) - extract(epoch from
(date('2011-03-19' / 3600
-- it must be 24 (hours), only occurs in march 19,2011
-- in v. 8.0 work fine!!
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS]
POSTGRESQL BUG REPORT TEMPLATE
Your name : Ricardo Caesar Lenzi
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : Intel Pentium
Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.16 (Conectiva Linux)
PostgreSQL version (example: PostgreSQL-7.1.1): PostgreSQL-7.2devel
Compiler used (example: gcc 2.95.2) : 2.91.66
Please enter a FULL description of your problem:
All the postgres functions, when using python interface, returns values
in wrong data type, text instead integer or float.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
Table structure:
ricardo=# \d contato
Table "contato"
Column | Type | Modifiers
+-+-
id_contato | integer | default nextval('contato_id'::text)
nome | text|
fone1 | text|
fone2 | text|
email | text|
Indexes: contato_ix1,
contato_ix2
Python program, using postgresql-7.1.3 server:
[ricardo@ricardo ricardo]$ python
Python 1.5.2 (#1, Jun 18 2000, 03:54:39) [GCC egcs-2.91.66 19990314/Linux]
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import pg
>>> db=pg.connect("ricardo")
>>> c=db.query("select count(*) from contato").getresult()[0][0]
>>> print repr(c), type(c)
'27'
>>> c=db.query("select sum(id_contato) from contato").getresult()[0][0]
>>> print repr(c), type(c)
'475'
>>> c=db.query("select nextval('contato_id')").getresult()[0][0]
>>> print repr(c), type(c)
'1'
Python program, using postgresql-7.1.2 server:
[ricardo@ricardo ricardo]$ python
Python 1.5.2 (#1, Jun 18 2000, 03:54:39) [GCC egcs-2.91.66 19990314/Linux]
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import pg
>>> db=pg.connect("ricardo")
>>> c=db.query("select count(*) from contato").getresult()[0][0]
>>> print repr(c), type(c)
27
>>> c=db.query("select sum(id_contato) from contato").getresult()[0][0]
>>> print repr(c), type(c)
475
>>> c=db.query("select nextval('contato_id')").getresult()[0][0]
>>> print repr(c), type(c)
1
If you know how this problem might be fixed, list the solution below:
-
--
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
