Re: SRF, JDBC and result info
От | ntinos@aueb.gr |
---|---|
Тема | Re: SRF, JDBC and result info |
Дата | |
Msg-id | courier.42318C40.00006F25@red.servers.aueb.gr обсуждение исходный текст |
Ответ на | Re: SRF, JDBC and result info (ntinos@aueb.gr) |
Список | 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@aueb.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@aueb.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
В списке pgsql-general по дате отправления: