Re: gset updated patch - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: gset updated patch
Date
Msg-id CAFj8pRC7YE+Za3qsc3BsWjTzkV3VLSsHtAY0Zw9mNHKV5jPvrA@mail.gmail.com
Whole thread Raw
In response to Re: gset updated patch  (Piyush Newe <piyush.newe@enterprisedb.com>)
List pgsql-hackers
Hello

2012/11/27 Piyush Newe <piyush.newe@enterprisedb.com>:
>
> Just another thought !
>
> When we are setting up the variable using \gset, I feel their should be a
> provision
> to drop a particular variable.
>
> Internally, all the variables are set into "VariableSpace" linked-list. We
> should provide
> a command to Drop a particular variable, because in some cases unnecessary
> the
> variable count is increasing & consuming a VariableSpace.
>
> We might use two different variables for two different queries, but if we
> are not going
> to use the first variable in further execution, then unnecessary we are
> consuming a
> space for 1st variable in the "VariableSpace". In such cases, user will drop
> the 1st
> variable.
>
> This particular feature/mechanism is useful for a queries which returns a
> single row.
> So user will be using such technique for multiple queries. In such cases,
> user might
> need to create multiple variables. Hence I thoughts so.
>

sorry, I don't understand

now, when we set variable by empty value, then we remove variable

???

regards

Pavel

> Let me know if such mechanism is already exists & I am missing the same.
>
>
> On Mon, Nov 19, 2012 at 9:42 PM, Dimitri Fontaine <dimitri@2ndquadrant.fr>
> wrote:
>>
>> "Karl O. Pinc" <kop@meme.com> writes:
>> > Yes. I'm wrong.  For some reason I thought you could use DO to make
>> > an anonymous code block that would act as a SETOF function,
>> > allowing RETURN NEXT expr (et-al) to be used in the
>> > plpgsql code, allowing DO to return table results.
>> > (Or, perhaps, instead, be used in place of a table in a SELECT
>> > statement.)  Oh well.
>>
>> My key for remembering about that point is that DO is a utility command,
>> not a query. Now, the proposal I pushed last time we opened that very
>> can of worms was to have inline functions rather than anonymous code
>> blocks:
>>
>>    WITH FUNCTION foo(integer) returns bigint language SQL AS $$
>>     SELECT $1 + 1;
>>    $$,
>>
>> Not sure how much that relates to $topic, but still something that
>> raises in my mind with enough presence that I need to write about it so
>> that it stops calling for attention :)
>>
>> Regards,
>> --
>> Dimitri Fontaine
>> http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support
>>
>>
>> --
>> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
>
>
> --
> --
> Piyush S Newe
> Principal Engineer
> EnterpriseDB
> office: +91 20 3058 9500
> www.enterprisedb.com
>
> Website: www.enterprisedb.com
> EnterpriseDB Blog: http://blogs.enterprisedb.com/
> Follow us on Twitter: http://www.twitter.com/enterprisedb
>
> This e-mail message (and any attachment) is intended for the use of the
> individual or entity to whom it is addressed. This message contains
> information from EnterpriseDB Corporation that may be privileged,
> confidential, or exempt from disclosure under applicable law. If you are not
> the intended recipient or authorized to receive this for the intended
> recipient, any use, dissemination, distribution, retention, archiving, or
> copying of this communication is strictly prohibited. If you have received
> this e-mail in error, please notify the sender immediately by reply e-mail
> and delete this message.
>



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: MySQL search query is not executing in Postgres DB
Next
From: Pavel Stehule
Date:
Subject: Re: MySQL search query is not executing in Postgres DB