Re: [HACKERS] Memory deallocation after calling cast function
Andres Freund writes: > On 2014-06-17 21:09:25 +0530, Abhijit Menon-Sen wrote: >> At 2014-06-17 11:32:37 -0400, br...@momjian.us wrote: >>> Uh, what is replacing SRFs? CTEs? >> I don't think Tom was referring to SRFs in general, only putting them >> directly into the targetlist of a SELECT. > And the primary reason for using SRFs in the targetlist has gone away > due to LATERAL. Exactly. LATERAL does what you usually want from a SRF in the targetlist, and it doesn't have bizarre semantics when you use more than one. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Memory deallocation after calling cast function
On 2014-06-17 21:09:25 +0530, Abhijit Menon-Sen wrote: > At 2014-06-17 11:32:37 -0400, br...@momjian.us wrote: > > > > > SRFs in the SELECT targetlist tend to leak memory; this is not easily > > > fixable, and nobody is likely to try hard considering the feature's on > > > the edge of deprecation anyhow. > > > > Uh, what is replacing SRFs? CTEs? > > I don't think Tom was referring to SRFs in general, only putting them > directly into the targetlist of a SELECT. And the primary reason for using SRFs in the targetlist has gone away due to LATERAL. It's now possible to pass data from tables to a SRF, that previously wasn't possibly unless you'd used a SRF in the targetlist. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Memory deallocation after calling cast function
At 2014-06-17 11:32:37 -0400, br...@momjian.us wrote: > > > SRFs in the SELECT targetlist tend to leak memory; this is not easily > > fixable, and nobody is likely to try hard considering the feature's on > > the edge of deprecation anyhow. > > Uh, what is replacing SRFs? CTEs? I don't think Tom was referring to SRFs in general, only putting them directly into the targetlist of a SELECT. -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Memory deallocation after calling cast function
On Tue, Jun 3, 2014 at 03:59:45PM -0400, Tom Lane wrote: > Soroosh Sardari writes: > > I have problem with memory deallocation. look at the following queries > > > 1- create table test01(a) as select generate_series(1,1)::int8 ; > > Do it as, eg, > > create table test01(a) as select g::int8 from generate_series(1,1) g; > > SRFs in the SELECT targetlist tend to leak memory; this is not easily > fixable, and nobody is likely to try hard considering the feature's on > the edge of deprecation anyhow. Uh, what is replacing SRFs? CTEs? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Memory deallocation after calling cast function
Soroosh Sardari writes: > I have problem with memory deallocation. look at the following queries > 1- create table test01(a) as select generate_series(1,1)::int8 ; Do it as, eg, create table test01(a) as select g::int8 from generate_series(1,1) g; SRFs in the SELECT targetlist tend to leak memory; this is not easily fixable, and nobody is likely to try hard considering the feature's on the edge of deprecation anyhow. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
