Re: 8.1.3, libpq, PQprepare, plpgsql function, and partitioned tables

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "shakahshakah(at)gmail(dot)com" <shakahshakah(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: 8.1.3, libpq, PQprepare, plpgsql function, and partitioned tables
Date: 2006-04-03 01:13:46
Message-ID: 20060403011346.GD4474@ns.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> "shakahshakah(at)gmail(dot)com" <shakahshakah(at)gmail(dot)com> writes:
> > Am I correct in assuming that when Postgres prepared the SQL to execute
> > the "insert function" that the existing rules on the base table were
> > also resolved at that time? If so, is there any way to avoid that
> > behavior?
>
> Yes; no. We are working on infrastructure to automatically redo
> prepared plans when relevant catalog entries change, but it's not there
> today :-(

Wouldn't it be possible to use 'execute' instead and have the plan
re-generated each time that way? It'd be less efficient but I think
it'd work as a work-around...

Just some thoughts,

Thanks,

Stephen

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message HIRA SIROJUDIN ABBAS 2006-04-03 02:33:03 help me...
Previous Message Tom Lane 2006-04-03 00:27:24 Re: Database security granularity