Re: actualised funcs typmod patch - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: actualised funcs typmod patch
Date
Msg-id 162867790911171151r5da5d0c3teb6701f8c307b014@mail.gmail.com
Whole thread Raw
In response to Re: actualised funcs typmod patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: actualised funcs typmod patch
List pgsql-hackers
2009/11/17 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2009/11/17 Tom Lane <tgl@sss.pgh.pa.us>:
>>> My point is that if we release 8.5 with these semantics (which as far
>>> as I can tell were not designed, but just fell out of what made for the
>>> shortest patch) then we'll be stuck with them thereafter.
>
>> 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.

sorry, it's problem in my english - too simply language. This cannot
change an behave of older applications. Sure - if somebody use
explicit typmod in CREATE FUNCTION statement, then he get different
behave. But he have to do it explicitly in 8.5. It is only main
opinion - I thing, so nobody can expect surprise. In plpgsql the
behave is practically same. The difference is one - neighbourhood has
more informations about function interface.

one positive point. It fixes one small bug:

postgres=# create or replace function foo(a varchar(3))
returns varchar as $$
begin a := 'abcdef'; return a;
end;
$$ language plpgsql;
CREATE FUNCTION
postgres=# select foo('omega'); foo
────────abcdef
(1 row)

>
> 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.
>

yes, I am sorry. I hope, so there will be some people who help with
creating documentation. What I know, it's need:

* drop notices about dropping typmod in CREATE FUNCTION statement
* enhancing documentation about pg_proc
* add note to ALTER FUNCTION about impossibility to change typmod -
the reason is same like impossibility to change defaults or names.

The new behave should be transparent for user.

Regards
Pavel Stehule
>                        regards, tom lane
>


pgsql-hackers by date:

Previous
From: Jaime Casanova
Date:
Subject: Re: Syntax for partitioning
Next
From: Alvaro Herrera
Date:
Subject: Re: patch - Report the schema along table name in a referential failure error message