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