2009/11/21 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2009/11/21 Andrew Dunstan <andrew@dunslane.net>:
>>> One possible problem: what type would these anonymous params be?
>
>> It is solved long time - without specification, any parameter is
>> 'unknown text'.
>
> Nonsense.
>
ok.
> We do have the ability to infer parameter types when parsing a SQL
> statement. That does not extend to any random PL being able to do it.
> In fact, NONE of them can do it, not even plpgsql. They all expect
> incoming parameter types to be predetermined.
>
When we use DO statement from clients without possibility to specify
type, an usedr have to specify type with explicit casting. Inside DO
statement or in USING clause. Then any outer value has type or is
unknown. When is unknown - then any usage needs explicit casting
inside DO body. When has type - there are no problem. But we will have
a way for passing a parameters.
an sample should be
DO $$ .... $$ USING psqlvar::text, psqlothervar numeric;
I don't expect typed variables inside psql. It's not impossible, but
why? There are pgScript and DO statement. Theoretically we can
identify the most common type for untyped variable in compile stage of
any PL. It have to be a similar mechanism like now - with existing
hooks it could not be a problem, but I don't thing it is necessary
(for DO stament - functions are different, because are registered in
moment when some related objects doesn't exist). Explicit casting in
USING clause is enough. It is safe and simply. Explicit casting is
less work then some bash regxep substitution alchemy.
> Without types *and* names, there is no point in considering parameters.
> And the problem with that, which is why we didn't put parameters into
> DO in the first place, is that it raises the minimum notational bar
> quite a lot. You might as well go ahead and define a temporary
> function.
>
I understand. It's reason why I don't propose named parameters.
p.s. I don't see sense of temporary functions, when we have a
anonymous block. All temporary objects are problematic - I have not a
reason, thing about temporary functions some else.
regards
Pavel Stehule
> regards, tom lane
>
