Re: gset updated patch - Mailing list pgsql-hackers
| From | Piyush Newe |
|---|---|
| Subject | Re: gset updated patch |
| Date | |
| Msg-id | CAML=0Spu4ZdYgZmADQgtA671jza746M-OOpEN9RT6-yTKe-UMw@mail.gmail.com Whole thread Raw |
| In response to | Re: gset updated patch (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
| Responses |
Re: gset updated patch
(Pavel Stehule <pavel.stehule@gmail.com>)
|
| List | pgsql-hackers |
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.
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:My key for remembering about that point is that DO is a utility command,
> 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.
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: