The client has to read the incoming data stream for indications of the
type of data that is coming next, then further read a description of
each field name, type, and nullabillity in the event it is a dataset.
It is not pretty. I don't know how the higher level interfaces handle
it, but here is some interesting reading on TDS. It has changed a bit
since 5.0, but the basics are the same.
http://www.sybase.com/content/1013412/tds34.pdf
Also, FreeTDS http://www.freetds.org is interesting. They have high
level interfaces but I haven't had to use them.
- Ian
On 7/27/05, Martijn van Oosterhout <kleptog@svana.org> wrote:
> On Wed, Jul 27, 2005 at 12:45:12PM +1000, Ezequiel Tolnay wrote:
> > Ezequiel Tolnay wrote:
> > >(...) A function is meant to return a
> > >result (or a set of results) of a predefined type *during* execution,
> > >whilst a stored procedure (...)
> >
> > I meant to say *after* instead of *during*. The capabilitie to return
> > results during execution could only be suported by stored procedures.
>
> I know this is being fiddly but in PostgreSQL a function doesn't have
> to return all its values in one go. It can, in a loop, do calculations,
> return a row, do more calculations, return a row and these rows can be
> received by the client in real time (ie not wait for completion).
>
> But your description of stored procedures was useful. It's basically
> more like a script you would feed to psql. You indicate that the
> procedure can return multiple sets. How is this handled by the client?
>
> If you're not returning data then it would be like a void function
> using NOTICE to communicate with the client.
>
> Still, thanks for the info...
>
> Have a nice day,
> --
> Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> > tool for doing 5% of the work and then sitting around waiting for someone
> > else to do the other 95% so you can sue them.
>
>
>