On Sat, 2007-02-03 at 15:51 -0800, Jeremy Drake wrote: > I am writing a set returning function in C. There are cases where I can > know definitively, upfront, that this function will only return one row. > I have noticed, through happenstance of partially converted function, that > I can mark a normal, non-set returning function as returning SETOF > something, while not utilizing the SRF macros and using PG_RETURN_DATUM, > and it still works as returning one row. > > I am wondering, if it is an acceptable optimization that if I know > up-front that a function will only return one row, to avoid all of the > SRF overhead of setting up a new memory context, and a function context > struct, and requiring an extra call to my function to tell Postgres that I > am done sending rows, to simply not use the SRF stuff and interact with > Postgres as though I was not returning SETOF? Is this a sane idea, or did > I just stumble into an accidental feature when I changed my CREATE > FUNCTION statement without changing my C code?
Well, I'd say its either an SRF or its not. If you want to do select * from myfunc(), then it has to be an SRF. You *can* have a function that returns a composite type, but that is executed in a slightly different manner. e.g. select myfunc() from oneRowTable; Either way you have the overhead of the scan, so I see no optimization by trying to remove the SRF stuff. So I think you've found a minor bug, not a feature. But how do we check for SRF macros? With difficulty or overhead, one of the two. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq