Re: [GENERAL] a column definition list is required for functions returning "record"

2016-08-26 Thread Merlin Moncure
On Fri, Aug 26, 2016 at 10:50 AM, Cachique wrote: > Hi > From the documentation... ( > https://www.postgresql.org/docs/current/static/sql-select.html ) > > 'Function calls can appear in the FROM clause. (This is especially useful > for functions that return result sets, but

Re: [GENERAL] a column definition list is required for functions returning "record"

2016-08-26 Thread Cachique
Hi >From the documentation... ( https://www.postgresql.org/ docs/current/static/sql-select.html ) 'Function calls can appear in the FROM clause. (This is especially useful for functions that return result sets, but any function can be used.) This acts as though the function's output were created

Re: [GENERAL] a column definition list is required for functions returning "record"

2016-08-26 Thread Alexander Farber
Thank you, I was just wondering if there is a simpler way... but ok On Fri, Aug 26, 2016 at 5:29 PM, Tom Lane wrote: > > I think you are looking for the RETURNS TABLE syntax. >

Re: [GENERAL] a column definition list is required for functions returning "record"

2016-08-26 Thread Tom Lane
Alexander Farber writes: > in 9.5.3 I have defined the following custom function: > CREATE OR REPLACE FUNCTION words_select_games(IN in_uid integer) > RETURNS SETOF RECORD AS > I have also unsuccessfully tried > RETURNS SETOF words_games, words_moves

[GENERAL] a column definition list is required for functions returning "record"

2016-08-26 Thread Alexander Farber
Good afternon, in 9.5.3 I have defined the following custom function: CREATE OR REPLACE FUNCTION words_select_games(IN in_uid integer) RETURNS SETOF RECORD AS $func$ BEGIN RETURN QUERY SELECT g.gid AS gid, EXTRACT(EPOCH FROM g.created)::int AS

Re: [GENERAL] Understanding Postgres Memory Usage

2016-08-26 Thread Tom Lane
Theron Luhn writes: > Okay, I got a semi-reproducible test case: > https://gist.github.com/luhn/2b35a9b31255e3a6a2e6a06d1213dfc9 > The one caveat is that the memory rise only happens when using a > HashAggregate query plan (included in the gist), which I can't find a way > to