typmod for custom type

On 02/16/2014 12:12 AM, James Harper wrote:

I have created a custom type called my_numeric, which is roughly the same as the existing numeric type. I have declared in, out, typmod_in, and typmod_out functions. I create a table like:

CREATE TABLE test (col1 my_numeric(6, 3));

And then do \d test and can see that col1 is declared as (6, 3), which I think confirms that my typmod_in and typmod_out function are correct.

But when I do:

INSERT INTO test VALUES ('12.34');

It behaves as though the typmod parameter to my in function (PG_GETARG_INT32(2)) is passed in as -1. The docs (http://www.postgresql.org/docs/9.3/static/sql-createtype.html) says of the arguments that "the third is the typmod of the destination column, if known (-1 will be passed if not).".

The value above looks valid to me. So what about the behavior is strange?

Am I doing something wrong? Don't I need to know the typmod of the destination column so I can confirm that the format of the string being passed in conforms to the type modifier specified (eg so I can reject '1234.5678' for col1 with an overflow error)?

It would help to see the actual code you used to create the new type,
for those that would be able to help.

Thanks

James

--
Adrian Klaver
adrian.klaver@gmail.com

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

James Harper <james.harper@bendigoit.com.au> writes:

I have created a custom type called my_numeric, which is roughly the same as the existing numeric type. I have declared in, out, typmod_in, and typmod_out functions. I create a table like:
CREATE TABLE test (col1 my_numeric(6, 3));

And then do \d test and can see that col1 is declared as (6, 3), which I think confirms that my typmod_in and typmod_out function are correct.

But when I do:

INSERT INTO test VALUES ('12.34');

It behaves as though the typmod parameter to my in function
(PG_GETARG_INT32(2)) is passed in as -1.

It might be. In at least some cases the parser will generate a value as
unconstrained my_numeric and then expect to be able to cast that to the
constrained subtype. Whether that's the case here or not, in general you
will need a length-coercion cast function to support a type like this.
IIRC, you can read about that in the CREATE CAST documentation.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general