From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Petr Jelinek <pjmodos(at)pjmodos(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: USING clause for DO statement |
Date: | 2009-11-21 20:46:54 |
Message-ID: | 162867790911211246t26e267dft18e8f0d303f0e73@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2009/11/21 Merlin Moncure <mmoncure(at)gmail(dot)com>:
> On Sat, Nov 21, 2009 at 3:32 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> 2009/11/21 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> 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;
>>>> $$ using :par1, ${USER};
>>>
>>> Ick. Double, triple ick. It is astonishing to me how many people think
>>> that the solution to today's problem is always to invent some weird new
>>> syntax to plaster over SQL. Which for some reason invariably involves
>>> dollar signs and/or curly braces ... there isn't even any originality
>>> involved :-(.
>>>
>>> Maybe we should accept one of these proposals, just so that it usurps
>>> that part of the syntax space forever and we can reject the next ten bad
>>> ideas out-of-hand. Of course, if the SQL committee ever gets around to
>>> defining curly braces as doing something, we'll be screwed.
>>>
>>> colon-foo is bad enough. Let's not add more.
>>
>> I have a no problem. Syntax should be defined later. there is simple
>> workaround (using shellvariables):
>>
>> psql ... -v user = $USER
>>
>>
>> I repeat it again and finish:
>>
>> proposal is related only to DO statement (what is Pg specific).
>> Doesn't propose psql changes, doesn't propose PL changes.
>
> I code all day long by editing various text files and pasting some/all
> of them into psql. Once in a while I \i a file from psql or cat foo |
> psql. Only the last method is addressed by using a wrapper script or
> "bash/psql -c"...wrappers aren't really a general solution. If psql
> could introduce variables into arbitrary sql somehow, I could load a
> bunch of variables in .psqlrc, have constants set up, etc.
>
> For example, when I have a constant (let's say, and advisory lock#) I
> want to define in a plpgsql function, I have a choice between three
> not very pleasant options:
> *) simply hard code the value
> *) look it up every time from a global control table
> *) wrap it in an immutable sql function
>
> I don't care much about the syntax, but it would be absolutely
> wonderful if psql could operate on a function body in some sort of
> regular way before it gets to the backend. if it solves
> parameterizing 'do' statements, so much the better.
you need C preprocessor or Oracle's packages ;)
Oracle's packages would be better.
Pavel
>
> merlin
>
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Richardson | 2009-11-21 20:49:33 | Re: ecpg & 8.3 -> 8.4 migration |
Previous Message | Tom Lane | 2009-11-21 20:40:42 | Re: Hot standby and removing VACUUM FULL |