Re: [PATCHES] to_char and Roman Numeral (RN) bug

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [PATCHES] to_char and Roman Numeral (RN) bug
Дата
Msg-id 200109072023.f87KN8H21740@candle.pha.pa.us
обсуждение исходный текст
Ответ на [PATCHES] to_char and Roman Numeral (RN) bug  ("Command Prompt, Inc." <pgsql-hackers@commandprompt.com>)
Список pgsql-hackers
I have checked this in CVS and it is working fine.  Karel, have you
fixed this?  I can't find a place where I have applied a fix for this.


> Good day,
> 
> Sorry to post to this list about a patch, but I seem to be having some
> difficult getting on the pgsql-patches list; keep getting an "illegal
> command" when I send it "subscribe", for some reason. At any rate:
> 
> In documenting the to_char() function for transformation of numbers to
> text, I noticed that the "RN" template character sequence was displaying
> some unusual behavior; specifically, unless in fill mode (with the "FM"
> sequence), it would either return the result of the last query executed
> derived from a to_char() result, or what appears to be a garbage pointer
> if there was no such last query.
> 
> Example output from PostgreSQL 7.1.3:
> -------------------------------------------------------
> lx=# SELECT to_char(485, 'RN');
>      to_char
> -----------------
>  UERY :command 1
> (1 row)
> 
> lx=# SELECT to_char(485, 'FMRN');
>  to_char
> ---------
>  CDLXXXV
> (1 row)
> 
> lx=# SELECT to_char(485, 'RN');
>  to_char
> ---------
>  CDLXXXV
> (1 row)
> 
> lx=# SELECT to_char(1000, 'RN');
>  to_char
> ---------
>  CDLXXXV
> (1 row)
> 
> lx=# SELECT 1, 2, to_char(900, '999');
>  ?column? | ?column? | to_char
> ----------+----------+---------
>         1 |        2 |  900
> (1 row)
> 
> lx=# SELECT to_char(485, 'RN');
>  to_char
> ---------
>   900
> (1 row)
> -------------------------------------------------------
> 
> Upon looking into src/backend/utils/adt/formatting.c, I noticed that for
> RN transforms:
> 
>   strcpy(Np->inout_p, Np->number_p);
> 
> was only being called within the IS_FILLMODE if block. Moving it out, and
> above that check seems to correct this behavior, and I've attached Patches
> for both today's pgsql CVS snapshot and postgresql-7.1.3. Both compile,
> but I've only tested the latter since my data path is not setup for
> pre-7.2, and it seems like a fairly small change.
> 
> I consider myself a competent programmer, but never having hacked on
> Postgres, I'm not 100% sure that this modification is totally correct
> (e.g., if there are any strange side-effects from doing this?), since I'm
> not even sure what the Np pointers are achieving in this instance. ;) I'm
> guessing its copying the actual output result into the output value's
> char* pointer, as that would explain the garbage pointer if it was never
> copied.
> 
> Any explanation would be greatly appreciated, as I'd like to document this
> apparent bug correctly.
> 
> 
> Regards,
> Jw.
> -- 
> jlx@commandprompt.com - John Worsley @ Command Prompt, Inc.
> by way of pgsql-hackers@commandprompt.com

Content-Description: 

[ Attachment, skipping... ]

Content-Description: 

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: ryan_rs@c4.com (Ryan)
Дата:
Сообщение: Re: Toast, Text, blob bytea Huh?
Следующее
От: johan27@advalvas.be
Дата:
Сообщение: I have a serious problem with hanging backends.:SELECT waiting