From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Petr Jelinek <pjmodos(at)pjmodos(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: USING clause for DO statement |
Date: | 2009-11-21 17:16:28 |
Message-ID: | 162867790911210916y27d5862i33c3ca9570e4e3d7@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2009/11/21 Petr Jelinek <pjmodos(at)pjmodos(dot)net>:
> 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.
no - this isn't a problem. Current design of DO statement allows only
single-use using. I cannot to wrap "do" statement. 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.
> Now, if/when we add support to put DO inside standard sql query, it would be
> vastly more useful to be able to use parameters. But adding that support
> will be probably least of our problems if we try to do that, and we might
> even want to use different syntax/behavior then, so I would really not rush
> with this.
It doesn't need too much, Petr - I thing, so all necessary is done.
And this proposal doesn't do incompatible changes in syntax. It add
only new optional clause.
>
> --
> Regards
> Petr Jelinek (PJMODOS)
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2009-11-21 17:36:22 | Re: Proposal: USING clause for DO statement |
Previous Message | Petr Jelinek | 2009-11-21 17:00:30 | Re: Proposal: USING clause for DO statement |