Re: gset updated patch

From: Piyush Newe <piyush(dot)newe(at)enterprisedb(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: "Karl O(dot) Pinc" <kop(at)meme(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: gset updated patch
Date: 2012-11-27 09:49:23
Message-ID: CAML=0Spu4ZdYgZmADQgtA671jza746M-OOpEN9RT6-yTKe-UMw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndquadrant(dot)fr>wrote:

> "Karl O. Pinc" <kop(at)meme(dot)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(at)postgresql(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2012-11-27 09:56:51 Re: ilist.h fails cpluspluscheck
Previous Message Jeff Davis 2012-11-27 09:46:58 Re: MySQL search query is not executing in Postgres DB