Tom Lane wrote:
> Gavin Sherry <swm@linuxworld.com.au> writes:
> > ... I think I'll bite the bullet and store the ON COMMIT data in the
> > system catalogues per SQL99. Thoughts?
>
> Seems like the very hard way, considering that there's no reason at all
> for the ON COMMIT status to survive a given backend run. I'd certainly
> vote against adding pg_class columns for it, if that's what you had
> in mind.
>
> I don't much like reintroducing the backend-local list of temp tables
> that existed in earlier releases, but maybe that's the best way to
> handle this feature. Anyone see a better way?
I never did like that backend-local list of temp rels. It was too hard
to make it obey the table semantics. I guess if you listed them by oid
you could get it to work.
Seems we should be able to put this info somewhere in the system tables.
Could we throw it into pg_description? We have paired down those system
tables so far there isn't a place to stash random stuff.
>
> > ... I would like to get this into 7.3, along with all the other
> > patches or features I've put my hand up for. What will be the
> > effective cut off for patches of this nature given 7.3 beta at the end
> > of the month.
>
> End of the month of course ... but I will say that the standards are
> going to rise as we get closer to the end. Patches submitted in the
> last week or so had better be right the first time.
Yep, we are not going to reject the stuff, but we are going to look at
it _really_ well. :-)
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073