Skip site navigation (1) Skip section navigation (2)

[PATCHES] to_char and Roman Numeral (RN) bug

From: "Command Prompt, Inc(dot)" <pgsql-hackers(at)commandprompt(dot)com>
To: Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: [PATCHES] to_char and Roman Numeral (RN) bug
Date: 2001-09-01 02:28:50
Message-ID: Pine.LNX.4.30.0108311854500.14708-300000@commandprompt.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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(at)commandprompt(dot)com - John Worsley @ Command Prompt, Inc.
by way of pgsql-hackers(at)commandprompt(dot)com

Attachment: pgsql-src-backends-utils-adt-formatting.c.diff
Description: text/plain (374 bytes)
Attachment: postgresql-7.1.3-src-backends-utils-adt-formatting.c.diff
Description: text/plain (374 bytes)

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2001-09-01 07:53:48
Subject: Re: Escaping strings for inclusion into SQL queries
Previous:From: Thomas LockhartDate: 2001-09-01 01:16:05
Subject: Re: INTERVAL type: SQL92 implementation

pgsql-patches by date

Next:From: Barry LindDate: 2001-09-01 02:29:41
Subject: Re: Read transactions don't work on 7.0.x db's
Previous:From: Thomas LockhartDate: 2001-09-01 01:16:05
Subject: Re: INTERVAL type: SQL92 implementation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group