It is well defined, because we insist that the gram.y transformation not depend on any changeable state.
That's my point -- whether we begin from the query string or the raw parsetree shouldn't make a difference. By not well-defined, I meant that if the user is changing GUC variables on the fly, they can't rely on their prepared query being planned under any particular datestyle (or search path, etc.), since they can't really predict when replanning will take place (e.g. an sinval overflow could occur spontaneously and cause all cached plans to be invalidated). This is similar to how search_path and pl/pgsql works right now -- we'll use the search_path in effect when the query is planned, which may or may not be what the user would expect.
-Neil
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
