2009/11/21 Merlin Moncure :
> On Sat, Nov 21, 2009 at 3:32 PM, Pavel Stehule
> wrote:
>> 2009/11/21 Tom Lane :
>>> Pavel Stehule writes:
Hypothetically - when we are able to pass any value to DO script, then
I don't see problem. If I use Andrew's design - ${shellvar} and add it
to
On Sat, Nov 21, 2009 at 3:32 PM, Pavel Stehule wrote:
> 2009/11/21 Tom Lane :
>> Pavel Stehule writes:
>>> Hypothetically - when we are able to pass any value to DO script, then
>>> I don't see problem. If I use Andrew's design - ${shellvar} and add it
>>> to psql parser, then I could to write
>>
2009/11/21 Tom Lane :
> Pavel Stehule writes:
>> Hypothetically - when we are able to pass any value to DO script, then
>> I don't see problem. If I use Andrew's design - ${shellvar} and add it
>> to psql parser, then I could to write
>
>> \set par1 world
>
>> do $$
>> begin
>> raise notice
Tom Lane wrote:
In any case I don't think that "getting stuff from
psql variables into a DO script" is the way to define the problem.
It's "getting stuff from shell variables into a DO script" that is the
real-world problem.
Indeed. But setting psql variables from the command line is easy. W
Pavel Stehule writes:
> Hypothetically - when we are able to pass any value to DO script, then
> I don't see problem. If I use Andrew's design - ${shellvar} and add it
> to psql parser, then I could to write
> \set par1 world
> do $$
> begin
> raise notice 'Helo, % and %', $1, $2;
> end;
>
> The main limitation of this type of approach is that it's hard to
> properly quote a variable value that might contain any random character
> sequence. However, that's also true of the variable-interpolation stuff
> Pavel was proposing. In any case I don't think that "getting stuff from
> psq
Andrew Dunstan writes:
> See my earlier comment:
>> Perhaps part of the problem is that psql can't interpolate its
>> variable into strings. Solving that might lessen the impetus for this,
>> and have other uses besides.
It seems to me that this is sliding down the wrong slope. You're
basicall
2009/11/21 Merlin Moncure :
> On Sat, Nov 21, 2009 at 1:24 PM, Pavel Stehule
> wrote:
>> 2009/11/21 Merlin Moncure :
>>> On Sat, Nov 21, 2009 at 12:36 PM, Andrew Dunstan
>>> wrote:
> Perhaps part of the problem is that psql can't interpolate its variable
> into strings. Solving that mig
On Sat, Nov 21, 2009 at 1:24 PM, Pavel Stehule wrote:
> 2009/11/21 Merlin Moncure :
>> On Sat, Nov 21, 2009 at 12:36 PM, Andrew Dunstan wrote:
Perhaps part of the problem is that psql can't interpolate its variable
into strings. Solving that might lessen the impetus for this, and have
2009/11/21 Merlin Moncure :
> On Sat, Nov 21, 2009 at 12:36 PM, Andrew Dunstan wrote:
>>> Perhaps part of the problem is that psql can't interpolate its variable
>>> into strings. Solving that might lessen the impetus for this, and have other
>>> uses besides.
>
> +1!
>
> This would have a _lot_ o
On Sat, Nov 21, 2009 at 12:36 PM, Andrew Dunstan wrote:
>> Perhaps part of the problem is that psql can't interpolate its variable
>> into strings. Solving that might lessen the impetus for this, and have other
>> uses besides.
+1!
This would have a _lot_ of uses.
merlin
--
Sent via pgsql-hac
Pavel Stehule wrote:
I would to use this
statement for some non trivial maintenance tasks - and I would to use
external parameter (from command line). My question is - what is a
good way for passing some value (from command line) to DO statement
body? I accept any mechanism.
See my earlie
2009/11/21 Petr Jelinek :
> I don't see point in having parameters for DO as an utility command. If you
> need to reuse some value you can define those variables at the beginning of
> code block in the language itself (in DECLARE section in plpgsql for
> example), defining them in outer SQL command
I don't see point in having parameters for DO as an utility command. If
you need to reuse some value you can define those variables at the
beginning of code block in the language itself (in DECLARE section in
plpgsql for example), defining them in outer SQL command does not really
help anything
2009/11/21 Tom Lane :
> Pavel Stehule writes:
>> 2009/11/21 Andrew Dunstan :
>>> 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 paramet
Pavel Stehule writes:
> 2009/11/21 Andrew Dunstan :
>> One possible problem: what type would these anonymous params be?
> It is solved long time - without specification, any parameter is
> 'unknown text'.
Nonsense.
We do have the ability to infer parameter types when parsing a SQL
statement. Th
Pavel Stehule wrote:
p.s. Maybe it is premature - We had to live with EXECUTE (without
USING clause) twelve years. But an life should be comfortable. I don't
would to wait twelve years :)
I think you should take heed of Tom's words:
I think adding onto DO capabilities is something we co
2009/11/21 Andrew Dunstan :
>
>
> Pavel Stehule wrote:
>>
>> What do you thing about this proposal?
>>
>>
>>
>
> I think it's premature. Before we start adding bells and whistles to the
> feature, let's give it a turn in the field.
why? It thing so not. My opinion - it is incomplete. It has simila
Pavel Stehule wrote:
What do you thing about this proposal?
I think it's premature. Before we start adding bells and whistles to the
feature, let's give it a turn in the field.
One possible problem: what type would these anonymous params be? (And,
BTW, don't kid yourself that there w
2009/11/21 Pavel Stehule :
> Hello,
>
> I am still thinking, about using DO statement from psql console. I am
> missing any parametrisation. It could not be a problem. All pl have a
> support for parameters, we have a libpq function PQexecParams - so we
> need only some "USING" clause. I propose fo
Hello,
I am still thinking, about using DO statement from psql console. I am
missing any parametrisation. It could not be a problem. All pl have a
support for parameters, we have a libpq function PQexecParams - so we
need only some "USING" clause. I propose following syntax (and using
from client
21 matches
Mail list logo
