> > 2. perhaps "global" could mean simply that
> the definition is global - if called for session and not
> exist in session, then session prepares it first from the
> global def. there would need to be a back reference in
> case the global def was changed or dropped.
> >
>
> Yes, this seems to be a good idea. Something like this
> would be easier
> to implement then having the whole process run in some
> shared memory
> space. The implementation could by like:
>
> 1. App cals SQL like "EXEC
> <statement_name>"
> 2. PG Engine looks first in local prepared statements as it
> does now
> 3. If it doesn't find it there it looks in public space
> 4. If it's found there copy both the SQL and the
> execution plan stored
> in global space to local process
> 5. Execute the statement as if it was prepared in local
> process.
>
> Simplified greatly, new implementation could
> "only" add steps 3 and 4 to
> current implementation of PREPARED statements.
I think it only makes sense if the prepared statement is in the session.
For example, say the Globally submitted statement is stmt: "select * from tab1"
assume Session #1 has search_path=schema1 Session #2 has search_path=schema2
if session #1 attempts to exec stmt, it prepare and use schema1
if session #2 attempts to use stmt, if prepared globally, disaster
in submitted globally, it is not prepared at all until used, but, if ever used, prepared in the current session's
environment. really more like a rule who's preparation is remembered in the session.
