Re: RfD: more powerful "any" types

2009/9/10 Hannu Krosing <hannu@krosing.net>:
> On Thu, 2009-09-10 at 21:30 +0200, Pavel Stehule wrote:
>> 2009/9/10 Tom Lane <tgl@sss.pgh.pa.us>:
>> > Pavel Stehule <pavel.stehule@gmail.com> writes:
>> >> 2009/9/10 Tom Lane <tgl@sss.pgh.pa.us>:
>> >>> 1. Allow the existing "any" pseudotype as an input argument type for PLs.
>> >>> (AFAICS this is simple and painless; about the only question is whether
>> >>> we want to keep using the name "any", which because of conflicting with
>> >>> a reserved word would always need the double quotes.)
>> >
>> >> I thing so this is possible - I see only one critical point - you
>> >> cannot validate source in validation time.
>> >
>> > How's it any different from anyelement?
>>
>> true, if I remember well, there is substitution from anyelement to int?
>>
>> maybe from this perspective can be good to separate polymorphic types
>> to some kinds:
>>
>> any - really unknown type - there is possible only check on null or
>> not null (and maybe some basic operations).
>> anytext - any value (substituted to text) in validation time
>> anynumeric - any value (substitued to integer) in validation time.
>
> I think that way madness lies.
>
> then we should have anyXXX types for almost any subsets of types
>
> anytime , anygeom, anypointpair, anymorethantwopaintgeom, etc...

true :(
>
> better have a (possibility of) validation at compile time and
> validation/error-throwing at runtime - the latter is needed anyway.
>

I have very bad experience with late validation - like plpgsql did. It
could to throw some exception too late (in production) - so this is
some way, where we have to be carefully. It easy to write dynamic
system - but this system should be dangerous in production. When I
started with PostgreSQL I disliked hard typing system, now I love it -
lot of things are predictable.

> Unless we are going to implement CHECK constraints for function
> arguments and then use constraint exclusion for selecting the correct
> function ;)
>
>> regards
>> Pavel Stehule
>>
>> >
>> >                        regards, tom lane
>> >
>>
>
>