[HACKERS] Type modifier parameter of input function

[Michael Schneider]

Hi,

whenever pg calls my input function, the type modifier parameter is 
ALWAYS (-1). If I specify a type modifier like


SELECT 'Hello World!'::my_string_type(MODIFIER1,MODIFIER2);

then pg:
1. calls the my_string_type-typmod_in function, and gets the correct result
2. calls the my_string_type-input function with type modifier parameter (-1)
3. calls the CAST(my_string_type AS my_string_type) function with the 
correct type modifier returned by the typmod_in function and the 
my_string_type pointer returned by the input function.


How can I convince pg to call the input function with the correct type 
modifier?


Thanks in advance

Regards

Michael





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

Re: [HACKERS] Type modifier parameter of input function

[Tom Lane]

Michael Schneider mschn...@mpi-bremen.de writes:
 whenever pg calls my input function, the type modifier parameter is 
 ALWAYS (-1).
 ...
 How can I convince pg to call the input function with the correct type 
 modifier?

You can't.  Per the comment in coerce_type:

 * For most types we pass typmod -1 to the input routine, because
 * existing input routines follow implicit-coercion semantics for
 * length checks, which is not always what we want here.  Any length
 * constraint will be applied later by our caller.An exception
 * however is the INTERVAL type, for which we *must* pass the typmod
 * or it won't be able to obey the bizarre SQL-spec input rules. (Ugly
 * as sin, but so is this part of the spec...)

If the SQL standard didn't have such bizarrely inconsistent rules for
the results of implicit vs explicit coercions to char(n) and varchar(n),
we'd have more flexibility here.

regards, tom lane

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