Heikki Linnakangas wrote: > Emmanuel Cecchet wrote: > > I just saw that this new patch was not considered because the previous > > version ended being rejected. > > Note that this version of the patch aims at supporting ONLY temp tables > > that are created AND dropped in the same transaction. We need to be able > > to use temp tables in transactions that are doing 2PC, but the temp > > table lifespan does not need to cross transaction boundaries. > > > > Please let me know if this patch could be integrated in 8.4. > > IMHO, this is just getting too kludgey. We came up with pretty good > ideas on how to handle temp tables properly, by treating the same as > non-temp tables. That should eliminate all the problems the latest patch > did, and also the issues with sequences, and allow all access to temp > tables, not just a limited subset. I don't think it's worthwhile to > apply the kludge as a stopgap measure, let's do it properly in 8.5. > > As a workaround, you can use a regular table instead of a temporary one. > If you create and drop the regular table in the same transaction (that's > the same limitation that latest patch has), you won't end up with a > bogus table in your database if the connection is dropped unexpectedly. > If your application uses multiple connections simultaenously, you'll > need a little bit of code in the application so that you don't try to > create a table with the same name in all backends. You could also create > a different schema for each connection, and do "set > search_path='semitempschemaX, public'", so that you can use the same > table name and still have separate tables for each connections.
Can someone tell me how this should be worded as a TODO item? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
