Re: functions returning records

From: fche(at)redhat(dot)com (Frank Ch(dot) Eigler)
To: alex(at)pilosoft(dot)com (Alex Pilosov)
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: functions returning records
Date: 2001-06-28 12:27:26
Message-ID: o5lmmcg575.fsf@touchme.toronto.redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


alex(at)pilosoft(dot)com (Alex Pilosov) writes:

: [...]
: Well, it shouldn't return, but instead save the location and longjmp to
: SPI_RESUME_jmp location. On a next call, instead of a function call, it
: should longjmp back to saved location. I have to admit its more complex
: than I originally thought, but probably doable.

Implementing (what are in effect) co-routines or continuations by
setjmp/longjmp is an inherently non-portable practice. (Think about
how at all SPI_RESUME_jmp *and* the user-defined-function's saved
location could both be valid places to longjmp to at, the same time.)
At the least, you would need some assembly language code, and
heap-allocated stacks. Take a look into what user-level threading
libraries do.

If you went down this avenue, you might decide that a reasonable way
to do this is in fact to rely on first-class threads to contain the
execution context of user-defined functions. You wouldn't have the
concurrency problems normally associated with threads (since the
server would still only activate one thread at a time).

- FChE

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2001-06-28 12:40:29 Re: functions returning records
Previous Message Oleg Bartunov 2001-06-28 12:22:03 Patch for multi-key GiST (current CVS)