[03:43] <blr> wgrant: might give circus a go at any rate, easy enough to move it to upstart if it isn't working for us
[03:44] <blr> although realistically we have a good amount of time with upstart
[03:51] <stub> cjwatson: yes, compiled form of functions and views references objects by object id and will often need to be recreated like this. Its a wart.
[03:52] <stub> cjwatson: You get to ignore it until PG throws an error in your face, at which point you copy pasta.
[06:42] <wgrant> stub: CREATE OR REPLACE FUNCTION preserves the OID.
[06:43] <wgrant> Also, I'm pretty sure the plan only survives for the life of the connection.
[06:43] <wgrant> Otherwise a function referencing a temp table would never work.
[06:44] <wgrant> Hm.
[06:44] <wgrant> "Once PL/pgSQL has made an execution plan for a particular command in a function, it will reuse that plan for the life of the database connection."
[06:45] <wgrant> "Note: In PostgreSQL 8.3 and later, saved plans will be replaced whenever any schema changes have occurred to any tables they reference. This eliminates one of the major disadvantages of saved plans. However, there is no such mechanism for function references, and thus the above example involving a reference to a deleted function is still valid."
[07:01] <stub> Its executing the compiled form of the function though, so things like NEW can fail because the definition of the table has changed, and it is trying to stuff a square shaped row in a round struct.
[07:02] <stub> But I always forget and forget the rules, and just deal when PG spits an error at me.
=== jelmer_ is now known as jelmer