Re: [BUGS] BUG #3323: Wrong charset for the lower and upper functions
Hi, I haven't seen this issue for windows console, but I don't think it affects my DB. Anyway, I'm using Unicode (UTF8), and this is the only problem I had. If it had something to do with the encoding, the results would be very different (such as the wrong character as result for the function). My guess is that the order is reversed for the ç only. I'll try to fix the windows console issue and tell you the results later. Thanks for your help. 2007/5/30, Euler Taveira de Oliveira <[EMAIL PROTECTED]>: 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/
[BUGS] BUG #3326: Invalid lower bound of autovacuum_cost_limit
The following bug has been logged online: Bug reference: 3326 Logged by: Galy Lee Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 Operating system: Red Hat 4. Description:Invalid lower bound of autovacuum_cost_limit Details: Hello I found some bugs which relative to the autovacuum_cost_limit GUC parameter. * Bug-1: Invalid lower bound of autovacuum_cost_limit autovacuum_vacuum_cost_limit should be the following value: autovacuum_vacuum_cost_limit = -1, or [1, 1] (0 should be prohibited. ) But 0 can also be accepted for autovacuum_vacuum_cost_limit now. This causes zero-division error for autovacuum: ERROR: floating-point exception DETAIL: An invalid floating-point operation was signaled. This probably means an out-of-range result or an invalid operation, such as division by zero. * Bug-2: 0-cost-limit for autovacuum worker When autovacuum_max_workers > autovacuum_vacuum_cost_limit, the above zero-division error also happened. * Bug-3: no GUC constrain check for pg_autovacuum The settings in pg_autovacuum are not checked enough now. Invalid value can be passed to autovacuum, this also causes some columns in pg_autovacuum has inconsistent upper and lower bound with their original GUC constrain. pg_autovacuum colum | definition | GUC constrain ++-- vac_base_thresh | integer| [0, INT_MAX] vac_scale_factor| real | [0.0, 100.0] anl_base_thresh | integer| [0, INT_MAX] anl_scale_factor| real | [0.0, 100.0] vac_cost_delay | integer| [-1, 1000] vac_cost_limit | integer| [-1, 1] freeze_min_age | integer| [0, 10] freeze_max_age | integer| [1, 20] The above table shows the wrong mapping between pg_autovacuum columns and GUC constrain. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #3327: Hi great site great work thank you!
The following bug has been logged online: Bug reference: 3327 Logged by: Johndhihj Email address: [EMAIL PROTECTED] PostgreSQL version: Unknown Operating system: Unknown Description:Hi great site great work thank you! Details: Hi great site great work thank you! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #3328: initialization complex types with domain column
The following bug has been logged online: Bug reference: 3328 Logged by: Sergey Morgalev Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4 Operating system: windows xp, free bsd Description:initialization complex types with domain column Details: Hello. When user defined complex type with user defined DOMAIN with NOT NULL AND DEFAULT attrubute, postgres can't initialize variable in DECLARE section of PROCEDURE for example: -- create some DOMAIN CREATE DOMAIN my_domain AS numeric DEFAULT 0 NOT NULL; -- create complex type CREATE TYPE t_my_type AS ( int id, name vachar, value my_domain ) PostgreSQL 8.2.4 does not allow the declare variable with type 't_my_type' in a FUNCTION CREATE OR REPLACE FUNCTION m_function() RETURNS SETOF t_my_type AS $$ DECLARE _my_var t_my_type; --- skipped -- ERROR: domain my_domain does not allow null values CONTEXT: PL/pgSQL function "my_function" line 4 at block variables initialization Ok. will declare the '_my_var' variable with type 'RECORD' and initialize record in the FUNCTION body. Postgres will cast the record var to t_my_type and allow return SETOF. But. When FUNCTION accept argument with complex type, it is not possible. PostgreSQL can't cast record to user defined type. It is not possible use complex types with such domains in procedures. In previous version - 8.2.1 it's worked normaly. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
