2009/11/17 Dimitri Fontaine <dfonta...@hi-media.com>:
> Le 17 nov. 2009 à 20:33, Tom Lane a écrit :
>>> We could to talk about it now. We are not hurry. But I would to see
>>> some progress in this area in next two months. This patch is simple
>>> and doesn't create any new rules or doesn't change behave.
>>
>> What do you mean it doesn't change the behavior? It establishes a
>> specific set of behaviors for functions with non-default typmods in
>> their arguments. If we just apply whatever was the easiest thing to
>> implement, without any discussion, we are very likely to regret it
>> later.
>>
>> It might be that what you've done is all fine, but I'd like some
>> discussion and consensus on the issues. Submitting an entirely
>> documentation-free patch is not the way to establish consensus.
>
> I'll try to help there, it's not really a review any more, but still it seems
> needed. Here's what I gather the specs of Pavel's work are by quick-reading
> through his patch:
>
> /*
> + * Don't allow change of input typmodes. Any change should
> break
> + * stored casts in prepared plans.
> + */
>
> The return type now can have a non -1 typmod given.
>
> [implementation details of parameterTypmodes and allParameterTypmodes left
> out, not well understood yet, does seem to be details rather than spec level
> things]
>
> + if (rettypmod != resttypmod && rettypmod != -1)
> + ereport(ERROR,
> +
> (errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
> + errmsg("return type mismatch in function declared to
> return %s",
> + format_type_with_typemod(rettype,
> rettypmod)),
> + errdetail("Actual return type is
> %s.",
> +
> format_type_with_typemod(restype, resttypmod))));
>
> So you need to return a decorated value I guess, or assign it to a retval
> which is of the right type, including typmod. Declaring a retval text to
> handle a RETURNS varchar(15) won't do it.
>
>
> + /* when typmodes are different, then foerce coercion too */
> + force_coerce = declared_typmod != -1 && declared_typmod !=
> actual_typmod;
>
> So if you declare typmods they are NOT part of the polymorphism (also per
> comment upthread) but you cannot change them and there's automatic coercion
> when only the typmod mismatches. I think that's what Tom wanted to avoid
> doing (because it breaks existing code assumptions and typmod coercion is not
> well defined).
>
> Here are some tests showing either the coercion of the argument (and failures
> to do it) or the return type typmod invalidity:
> + ERROR: cannot change parameter typmod of existing function
>
> + select typmodtest('a','bbbb'); -- outside plpgsql
> + ERROR: value too long for type character varying(3)
>
> + select typmodtest('aaaa','bbb'); -- return value
> + ERROR: value too long for type character varying(6)
> + CONTEXT: PL/pgSQL function "typmodtest" while casting return value to
> function's return type
>
>
> Then a great deal of changes that makes me cry in favor of having something
> human friendly around internal catalogs representation, all this BKI stuff
> IIUC.
>
> So the bulk of it is supporting return typemod declaration. This expands to
> OUT types, which can be cool:
>
> + create or replace function typmodtest(out a numeric(5,2),out b
> numeric(5,2), out c numeric(5,2))
>
>
> Hope this helps,
Thank you very much
> --
> dim
>
> PS: about the more than one anyelement type support in functions, I'd rather
> have a nice SQLish syntax around it. My proposal was sth like this:
>
> CREATE FUNCTION foo(a anyelement x, b anyelement x, c anyelement y)
> RETURNS anyelement y[]
> AS $$
> ...
> $$;
I would to wait with discussion about syntax. I am expecting similar
battle like about named parameters and I thing, so this can wait. But
I am sure, so We return to this and others ideas.
Regards
Pavel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
