2017-12-22 0:50 GMT+01:00 Melvin Davidson <melvin6925@xxxxxxxxx>: > > > > On Thu, Dec 21, 2017 at 12:07 PM, Vincenzo Romano <vincenzo.romano@xxxxxxxxxxx> wrote: >> >> 2017-12-21 17:56 GMT+01:00 Tom Lane <tgl@xxxxxxxxxxxxx>: >> > Vincenzo Romano <vincenzo.romano@xxxxxxxxxxx> writes: >> >> 2017-12-21 17:52 GMT+01:00 Tom Lane <tgl@xxxxxxxxxxxxx>: >> >>> You have to schema-qualify the temp function name when calling it, too. >> > >> >> So search_path is not used with functions? >> > >> > pg_temp is explicitly ignored when searching for functions/operators. >> > Otherwise, installing a trojan horse is just too easy. >> > >> > regards, tom lane >> >> I'm not sure whether this decision actually makes PG more scure. >> But, anyway, thanks for the insight: I've just found the >> documentations for this. >> >> -- >> Vincenzo Romano - NotOrAnd.IT >> Information Technologies >> -- >> NON QVIETIS MARIBVS NAVTA PERITVS >> > > Aside from the simple explanations you have received, I question your justification for even having a temporary function. > Functions are only entries in the system catalogs and as such, take up just a tiny amount of physical space. In addition, > if you ever need it again, you will have to expend time recreating it. Why not just once and keep it? > Hi. Thanks for your comment. The reason for having temporary object, in my current design, is to have something shadowing something else on a per session basis, thanks to the search_path variable. It's not simply a matter or storage room or access speed. Not at all to me. If you use, for example: SET search_path to pg_temp,"$user",public; you can put general stuff in public, per-user data in "$user" and per session data in pg_temp. Then the "name resolution" will follow the above priority during lookup. And, as I put more and more logics in the DB, having temporary functions gives me a simple, clean and yet powerful design. As soon as my applications connect, they run SELECT * FROM f_application_init( 'MYAPPNAME' ). That function (which is not temporary) will setup the DB-level, the user-level and the session-level stuff. Currently it eats about 500 msec to run and it's run only once per session. So, the answer to your question is: "why not if it can be useful " -- Vincenzo Romano - NotOrAnd.IT Information Technologies -- NON QVIETIS MARIBVS NAVTA PERITVS
