Thread: typmod for custom type
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_outfunction 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 thedestination column, if known (-1 will be passed if not).". Am I doing something wrong? Don't I need to know the typmod of the destination column so I can confirm that the format ofthe string being passed in conforms to the type modifier specified (eg so I can reject '1234.5678' for col1 with an overflowerror)? Thanks James
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 declaredin, 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_outfunction 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 thedestination 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 formatof the string being passed in conforms to the type modifier specified (eg so I can reject '1234.5678' for col1 withan 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
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 declaredin, 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_outfunction 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