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 по дате отправления:
Следующее
От: johan27@advalvas.beДата:
Сообщение: I have a serious problem with hanging backends.:SELECT waiting