Re: first time hacker ;) messing with prepared statements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: PFC <lists(at)peufeu(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: first time hacker ;) messing with prepared statements
Date: 2008-03-31 14:58:46
Message-ID: 27845.1206975526@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

PFC <lists(at)peufeu(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-03-31 15:32:43 Re: [HACKERS] ANALYZE getting dead tuple count hopelessly wrong
Previous Message Tom Lane 2008-03-31 14:16:44 Re: Commit fest status