Re: [HACKERS] CREATE TEMP TABLE .... ON COMMIT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] CREATE TEMP TABLE .... ON COMMIT
Date: 2002-08-14 05:52:30
Message-ID: 5343.1029304350@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Gavin Sherry <swm(at)linuxworld(dot)com(dot)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 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-08-14 06:05:08 Re: [HACKERS] CREATE TEMP TABLE .... ON COMMIT
Previous Message Bruce Momjian 2002-08-14 05:49:06 Re: FUNC_MAX_ARGS benchmarks

Browse pgsql-patches by date

  From Date Subject
Next Message Gerhard Hintermayer 2002-08-14 06:04:35 Re: [INTERFACES] libpgtcl modifications
Previous Message Bruce Momjian 2002-08-14 05:47:57 Re: improve FOUND in PL/PgSQL