Re: SRF, JDBC and result info

From: ntinos(at)aueb(dot)gr
To: ntinos(at)aueb(dot)gr
Cc: Kris Jurka <books(at)ejurka(dot)com>, Postgresql General <pgsql-general(at)postgresql(dot)org>
Subject: Re: SRF, JDBC and result info
Date: 2005-03-11 12:17:04
Message-ID: courier.42318C40.00006F25@red.servers.aueb.gr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Solution found! Thanks to Kris Jurka's advise I managed to pass this info
using: elog(INFO,... or elog(NOTICE,... . These messages together with
.getWarnings() do the job. :

e.g. message returned by the SQLWarning:

SNOTICEC00000M#SUCCESSFUL EXECUTION. NO TUPLES FROM PEER(S):
mobileb#Ftestmybuild.cL2558Ranswer

Getting the plain message is then trivial (e.g. using flag chars like '#'
above)

Of cource the appropriate logging must be set in postgresql.conf.

Just in case somenone wants to do the same thing.
I dont know if this is the best solution (or if any other exists) but it
surely works.

Regards,
Ntinos Katsaros

PS: libpq has nothing to do with the above :-)!

ntinos(at)aueb(dot)gr writes:

> Thank you very much for your reply. The thing is that my SRF is written in
> C, not plpgsql, but I'll look into RAISE NOTICE anyway.(I think there is
> something equevalent in libpq)
>
> Thanks again,
> Ntinos Katsaros
>
> Kris Jurka writes:
>
>>
>>
>> On Tue, 8 Mar 2005 ntinos(at)aueb(dot)gr wrote:
>>
>>> Hi everybody!
>>>
>>> I have an SRF which is called from a JAVA app with JDBC. Everything
>>> works fine and I want now to be able to pass some result-related info to
>>> my app. It is not about the format of the results (ResultSetMetaData) or
>>> something like that.
>>>
>>> Is it possible to return some string (or other type of)info together
>>> with the result tuples (even if it requiers some hacking i.e. there is
>>> no provision for something like that)? Any ideas?
>>>
>>
>> The only idea that comes to mind is using RAISE NOTICE in your plpgsql
>> function and Statement or ResultSet .getWarnings() on the Java side to
>> retrieve that info. There really isn't any other out of band data path.
>>
>> Kris Jurka
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 4: Don't 'kill -9' the postmaster
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Steven Verhoeven 2005-03-11 12:26:07 sql question
Previous Message AL ELK 2005-03-11 11:54:56 more execution time