[HACKERS] [PATCHES] to_char and Roman Numeral (RN) bug

[Command Prompt, Inc.]

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.
-- 
[EMAIL PROTECTED] - John Worsley @ Command Prompt, Inc.
by way of [EMAIL PROTECTED]


3976a3977
>   strcpy(Np->inout_p, Np->number_p);
3979d3979
<   strcpy(Np->inout_p, Np->number_p);
3982c3982
<   else
---
>   else {
3983a3984
>   }
3986a3988
>   strcpy(Np->inout_p, 
>str_tolower(Np->number_p));
3989d3990
<   strcpy(Np->inout_p, 
str_tolower(Np->number_p));
3992c3993
<   else
---
>   else {
3993a3995
>   }


3978a3979
>   strcpy(Np->inout_p, Np->number_p);
3981d3981
<   strcpy(Np->inout_p, Np->number_p);
3984c3984
<   else
---
>   else {
3985a3986
>   }
3988a3990
>   strcpy(Np->inout_p, 
>str_tolower(Np->number_p));
3991d3992
<   strcpy(Np->inout_p, 
str_tolower(Np->number_p));
3994c3995
<   else
---
>   else {
3995a3997
>   }



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

[HACKERS] PL/pgSQL RENAME bug?

[Command Prompt, Inc.]

Good day,

My name is John Worsley, I'm one of the authors of the new O'Reilly
PostgrSQL book. We're wrapping up the PL/pgSQL chapter's technical edit
right now, but there are a couple of concerns that I was hoping someone
might be able to help with.

Mainly, the existing documentation on the RENAME statement seems
inaccurate; it states that you can re-name variables, records, or
rowtypes. However, in practice, our tests show that attempting to RENAME
valid variables with:

  RENAME varname TO newname;

...yeilds a PL/pgSQL parse error, inexplicably. If I try the same syntax
on a non-declared variable, it actually says "there is no variable" with
that name in the current block, so...I think something odd is happening. :)

I believe we have only gotten RENAME to work with either the NEW or OLD
record variables when using PL/pgSQL with triggers, but the documentation
suggests that this should be a general-purpose statement.

Any assistance would be greatly appreciated. :)

The RENAME statement seems kind of odd, since it seems that you could just
as easily declare a general variable with the right name to begin with,
and maybe that's why this isn't apparently documented anywhere else? I
just want to make sure the documentation is both accurate and complete.


Kind Regards,
Jw.
-- 
John Worsley, Command Prompt, Inc.
[EMAIL PROTECTED] by way of [EMAIL PROTECTED]


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]