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
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) |