Re: Proposal: USING clause for DO statement
От | Pavel Stehule |
---|---|
Тема | Re: Proposal: USING clause for DO statement |
Дата | |
Msg-id | 162867790911210841x7c096cblc8fba525401d5b80@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal: USING clause for DO statement (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Proposal: USING clause for DO statement
|
Список | pgsql-hackers |
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 >
В списке pgsql-hackers по дате отправления: