On Sat, 13 Oct 2001, Bill Studenmund wrote: > On Sat, 13 Oct 2001, Tom Lane wrote: > > > I also wonder how the fixed, single-level namespace search path you > > describe interacts with the SQL rules for schema search. (I don't > > actually know what those rules are offhand; haven't yet read the schema > > parts of the spec in any detail...) > > Should be independent. The searching only happens when you are not in the > "standard" package, and you give just a function name for a function. > The searching would only happen in the current schems. If > you give a schema name, then I'd expect PG to look in that schema, in > standard, for that function. If you give both a schema and package name, > then PG would look in that package in that schema.
My description of namespaces seems to have caused a fair bit of confusion. Let me try again. The ability of the package changes to automatically check standard when you give an ambiguous function name while in a package context is a convenience for the procedure author. Nothing more. It means that when you want to use one of the built in functions (date_part, abs, floor, sqrt etc.) you don't have to prefix it with "standard.". You can just say date_part(), abs(), floor(), sqrt(), etc. The only time you need to prefix a call with "standard." is if you want to exclude any so-named routines in your own package. I've attached a copy of a package I wrote as part of testing package initializers and package global variables. It is an adaptation of the Random package described in Chapter 8 of _Oracle8 PL/SQL Programming_ by Scott Urman. Other than adapting it to PostgreSQL, I also tweaked the RandMax routine to give a flat probability. Note the use of date_part() in the BODY AS section, and the use of rand() in randmax(). Both of these uses are the ambiguous sort of function naming which can trigger the multiple searching. Since they are in plpgsql code, they get parsed in the context of the random package. So when each of them gets parsed, parse_func first looks in the random package. For rand(), it will find the rand() function and use it. But for date_part(), since there isn't a date_part function in the package, we use the one in standard. If we didn't have this ability, one of the two calls would need to have had an explicit package with it. There are two choices (either "standard." would be needed for date_part(), or "random." for rand()), but I think both would lead to problems. Either choice makes the syntax heavy, for little gain. Also, if we scatter the package name throughout the package, if we ever want to change it, we have more occurences to change. Does that make more sense? Take care, Bill
create or replace package random as declare v_seed 'float8', v_Multiplier 'float8', v_incriment 'float8' language 'plpgsql' body as ' begin v_Multiplier := 22695477; v_incriment := 1; v_seed := date_part(''epoch'', timestamp ''now''); return NULL; end; 'language 'plpgsql' function changeseed (float8) returns float8 as ' begin v_seed := $1; return 0; end; ' language 'plpgsql' function rand () returns float8 as ' begin v_seed := (v_multiplier * v_seed + v_incriment) % ( 2::float8 ^ 32); return (v_seed/(2^16)) % 32768::float8; end; ' language 'plpgsql' function randmax (float8) returns float8 as ' begin return rand() * $1 / 32768 + 1; end; ' language 'plpgsql';
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly