Re: [COMMITTERS] [WEBMASTER] 'www/html main.html'

Modified Files:
main.html
Log Message:
Add mention of TEMP tables.

Bruce, would this be a good time to start the v6.5 release notes?
Certainly the temp tables capability would make the short list of
"highlighted features" in the 1-paragraph-per-topic summary above the
one-liners.

Do you want to start the v6.5 section in release.sgml? Also, we
apparently have not yet gotten the v6.4.2 release notes in there either,
so perhaps you could drop those in also? I'll polish the markup as
needed...

- Tom

OK, got to finish temp table and commit them first.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Modified Files:
main.html
Log Message:
Add mention of TEMP tables.

Bruce, would this be a good time to start the v6.5 release notes?
Certainly the temp tables capability would make the short list of
"highlighted features" in the 1-paragraph-per-topic summary above the
one-liners.

Do you want to start the v6.5 section in release.sgml? Also, we
apparently have not yet gotten the v6.4.2 release notes in there either,
so perhaps you could drop those in also? I'll polish the markup as
needed...

- Tom

OK, got to finish temp table and commit them first.

Don't know if you noticed my statement in another thread.

I think temp tables could confuse any function that uses the
prepared/saved plan feature of SPI manager. If such a
function called once saved a plan for a temp table named
'test', and later called again but 'test' is now another
table, probably the parsetree and plan might point to the old
(wrong, not anymore existent) table.

Should not be a real drawback against temp tables. But maybe
something to mention in the release notes.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

OK, got to finish temp table and commit them first.

Don't know if you noticed my statement in another thread.

I think temp tables could confuse any function that uses the
prepared/saved plan feature of SPI manager. If such a
function called once saved a plan for a temp table named
'test', and later called again but 'test' is now another
table, probably the parsetree and plan might point to the old
(wrong, not anymore existent) table.

Yes. There are going to be limitations to the temp tables. Not sure
how what the limitations are going to be..

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

-----BEGIN PGP SIGNED MESSAGE-----

"Bruce" == Bruce Momjian <maillist@candle.pha.pa.us> writes:

Bruce> Yes. There are going to be limitations to the temp tables.
Bruce> Not sure how what the limitations are going to be..

As a possible suggestion...I know Sybase requires that temp tables
have names that begin with a `#'. This avoids the problem of
shadowing ordinary names.

roland
- --
PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD Custom Software Solutions
roberts@panix.com 101 West 15th St #4NN
rbroberts@acm.org New York, NY 10011

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNrZgIuoW38lmvDvNAQGW0gP9Egug1ICjbI9u93oXnWtWuGFQ+SV9XdEK
CpSkEiGbFBIB3MgXVc+6sCTbAsL5Y3RVEM3G0p91f/frFZVCpJYwuqvhxM6NHf3U
VUuHXUIBKwFUJsv/+t687/dlzX3e6jVUGx8BW++SrrpcDOHWmCMBJK+9v+gJqRum
axGwmGJgBZw=
=Q37n
-----END PGP SIGNATURE-----

-- Start of PGP signed section.

"Bruce" == Bruce Momjian <maillist@candle.pha.pa.us> writes:

Bruce> Yes. There are going to be limitations to the temp tables.
Bruce> Not sure how what the limitations are going to be..

As a possible suggestion...I know Sybase requires that temp tables
have names that begin with a `#'. This avoids the problem of
shadowing ordinary names.

That's cheezy. Here is my latest temp trick. Create a table and index,
create temp versions, insert into them, and test temp table removal.
This is the regression test. I am about to commit the code.

---------------------------------------------------------------------------

QUERY: CREATE TABLE temptest(col int);
QUERY: CREATE INDEX i_temptest ON temptest(col);
QUERY: CREATE TEMP TABLE temptest(col int);
QUERY: CREATE INDEX i_temptest ON temptest(col);
QUERY: DROP INDEX i_temptest;
QUERY: DROP TABLE temptest;
QUERY: DROP INDEX i_temptest;
QUERY: DROP TABLE temptest;
QUERY: CREATE TABLE temptest(col int);
QUERY: INSERT INTO temptest VALUES (1);
QUERY: CREATE TEMP TABLE temptest(col int);
QUERY: INSERT INTO temptest VALUES (2);
QUERY: SELECT * FROM temptest;
col
---
2
(1 row)

QUERY: DROP TABLE temptest;
QUERY: SELECT * FROM temptest;
col
---
1
(1 row)

QUERY: DROP TABLE temptest;
QUERY: CREATE TEMP TABLE temptest(col int);
-- restarts backend
\connect regression
QUERY: SELECT * FROM temptest;
ERROR: temptest: Table does not exist.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

As a possible suggestion...I know Sybase requires that temp tables
have names that begin with a `#'. This avoids the problem of
shadowing ordinary names.

Interesting. We could do something similar if supporting SQL92
conventions is impossible, but why not try for something compatible
first?

- Tom