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  (James Mansion <james@mansionfamily.plus.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Commit fest status
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] ANALYZE getting dead tuple count hopelessly wrong