Re: Patch: Add parse_type Function - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch: Add parse_type Function
Date
Msg-id 105927.1710969801@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch: Add parse_type Function  ("David E. Wheeler" <david@justatheory.com>)
Responses Re: Patch: Add parse_type Function
List pgsql-hackers
"David E. Wheeler" <david@justatheory.com> writes:
> Thanks, fixed in the attached patch.

Pushed with some editorialization.  Mostly, I whacked the
documentation around pretty heavily: we have a convention for what
examples in function descriptions should look like, and this wasn't
it.  Not entirely your fault, since some nearby entries in that
table hadn't gotten the word either.

Also, I made a point of adding tests for a corner case that
I initially thought the patch would not get right:

SELECT format_type(to_regtype('bit'), to_regtypemod('bit'));
 format_type 
-------------
 bit(1)
(1 row)

SELECT format_type(to_regtype('"bit"'), to_regtypemod('"bit"'));
 format_type 
-------------
 "bit"
(1 row)

This comes from the comment in format_type():

                /*
                 * bit with typmod -1 is not the same as BIT, which means
                 * BIT(1) per SQL spec.  Report it as the quoted typename so
                 * that parser will not assign a bogus typmod.
                 */

My initial fear was that we'd have to emit NULL for no typmod in order
to round-trip the second case, but it seems to work as-is, so that's good.
I left it emitting -1 for no typmod, and documented that explicitly.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: documentation structure
Next
From: Tom Lane
Date:
Subject: Re: documentation structure