On Tue, Jul 02, 2002 at 01:37:08AM +0200, Ferenc Engard wrote:
>
> If I understand well, I can create a cursor for a SELECT statement, and
> return that cursor. Well, it is better than nothing, but I fear it is
> not flexible enogh for me.
Maybe not for the solution you have right now, but you most likely can
rework things a bit to make it work.
> Here is an example from an interbase app. I have to declare that this is
> not my program, and I do not know IB, so forgive me if I say silly
> things...
>
> CREATE PROCEDURE VIEW_1_1
> (
> SZEMPONTID INTEGER,
> PARENT CHAR(10) CHARACTER SET WIN1250,
> ELNEVEZESTIPUSID INTEGER,
> RENDSZERKOD CHAR(16) CHARACTER SET WIN1250
> )
...
> The point is not what this proc does (in summary, it gets all the childs
> with their properties of a parent in a tree structure), but it cannot
> gather all the information with just one select, e.g. it gets some data
> from another (nontrivial) stored procedure.
>
> As I see, that 'suspend' command gives back the actual row (and the
> control) to the caller until it fetches the next row from this proc's
> return value. Do I interpret correct that this stored proc returns a
> cursor with structure described in the 'RETURNS' part, and which is not
> linked to a SELECT statement?
>
> Can I do something similar in PG? If not now, maybe in the (near)
> future?
Not in the way you currently have, as far as I could understand it. I didn't
read the procedure very attentively because it's horribly written in all caps,
and my eyes started scrambling the letters half way through.
-Roberto
--
+----| http://fslc.usu.edu/ USU Free Software & GNU/Linux Club |------+ Roberto Mello - Computer Science, USU -
http://www.brasileiro.net/ http://www.sdl.usu.edu/ - Space Dynamics Lab, Developer
"Data! I thought you were dead!" "No, Sir. I rebooted."
