Hello dear PostgreSQL developers,
I noticed the following strange behaviour with set-returning functions.
If sets are allowed seems to depend on the language the function is
written in, what makes conpletely no sense to me. See the following
functions x() and y(). x() is written in 'sql' and
On Tue, Feb 10, 2009 at 01:04:02AM +0100, Daniel Migowski wrote:
SELECT y(); -- fails with:
when you return set, you should use:
select * from y();
select function() is additional feature of sql functions.
depesz
--
Linkedin: http://www.linkedin.com/in/depesz / blog: http://www.depesz.com/
Hello
this limit will be removed at 8.4
in older version you have to use table notation like
select * from srf()
regards
Pavel Stehule
2009/2/10 Daniel Migowski dmigow...@ikoffice.de:
Hello dear PostgreSQL developers,
I noticed the following strange behaviour with set-returning functions.
Marshall, Steve wrote:
Any thoughts on whether or not this patch should be included in a future
PostgreSQL release? If so, any thoughts on additional testing, etc,
that needs to be done? Should the patch be added to a minor release of
8.3, or only included forward in 8.4? In my opinion,
What's the timing of the errors? Is there a chance that we are sending
the kill signal before the signal handling thread has actually started
*and created the named pipe*?
We set up the signal handling stuff pretty early, but we do seem to let
the postmaster continue it's work before it's up...
Pavel Stehule wrote:
Hello
this limit will be removed at 8.4
in older version you have to use table notation like
select * from srf()
regards
Pavel Stehule
hi,
that's funny. the 8.3 documentation i read said that in the
future you'd probably have to use select * from srf()
and
raf r...@raf.org writes:
does this mean that select srf() is no longer deprecated?
Well, it's got various issues --- in particular it's not real clear what
should happen if there's more than one SRF in a select list. It's
unlikely to go away though, especially not before we have an adequate
