Re: first time hacker ;) messing with prepared statements
| От | Tom Lane |
|---|---|
| Тема | Re: first time hacker ;) messing with prepared statements |
| Дата | |
| Msg-id | 27845.1206975526@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: first time hacker ;) messing with prepared statements (PFC <lists@peufeu.com>) |
| Ответы |
Re: first time hacker ;) messing with prepared statements
|
| Список | pgsql-hackers |
PFC <lists@peufeu.com> writes:
> Do the parse tree store fully qualified "schema.table" or
> "schema.function" ?
They store OIDs.
> I mean, if table T is mentioned in a parse tree which is stored, and the
> table is later dropped and recreated... or a column dropped... what
> happens ?
Dependencies take care of that --- if you drop the table, the statement
goes away too.
>> I also wonder whether statements should belong to schemas...
> Since they are basically an extremely simple form of a function, why not ?
> (but since part of the goodness on prepared statements is that they are
> stored in a fast hash cache, wouldn't that add too much overhead ?)
The lookup overhead would be trivial, I expect, compared to everything
else involved in a query. But what you'd have to work out is the
interaction between that and ordinary prepared statements, which
traditionally haven't had a schema name attached to the statement name.
(Come to think of it, if there's a statement FOO and I explicitly do
PREPARE FOO, what happens? Should the result depend on whether I've
used FOO earlier in the session?)
regards, tom lane
В списке pgsql-hackers по дате отправления: