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: