Re: JSON for PG 9.2

Robert Haas wrote:
> On Mon, Dec 12, 2011 at 4:08 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > On Mon, Dec 12, 2011 at 8:54 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >> There are way too many places that assume that the typmod can
> >> just be discarded.
> >
> > If true, that probably ought to be documented cos it sounds fairly important.
> >
> > Where and when is it true?
>
> I'm not going to go compile an exhaustive list, since that would take
> a week and I don't have any particular desire to invest that much time
> in it, but just to take a couple of simple examples:
>
> rhaas=# create or replace function wuzzle(numeric(5,2)) returns int as
> $$select 1$$ language sql;
> CREATE FUNCTION
> rhaas=# \df wuzzle
> List of functions
> Schema | Name | Result data type | Argument data types | Type
> --------+--------+------------------+---------------------+--------
> public | wuzzle | numeric | | normal
> public | wuzzle | integer | numeric | normal
> (2 rows)
>
> rhaas=# select pg_typeof(1.23::numeric(5,2));
> pg_typeof
> -----------
> numeric
> (1 row)
>
> There are a very large number of others. Possibly grepping for places
> where we do getBaseType() rather than getBaseTypeAndTypmod() would be
> a way to find some of them.

I think the most common one I see is with concatentation:

test=> select 'abc'::varchar(3) || 'def'::varchar(3);
?column?
----------
abcdef
(1 row)

It is not really clear how the typmod length should be passed in this
example, but passing it unchanged seems wrong:

test=> select ('abc'::varchar(3) || 'def'::varchar(3))::varchar(3);
varchar
---------
abc
(1 row)

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +