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
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 |
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 |