Temporary views

[Martijn van Oosterhout]

Currently you can create temporary tables that are deleted at the end of the
session. But how about temporary views? It's just a table with a rule so I
don't imagine it would be terribly difficult. Are there any issues I havn't
thought of?

While we're at it, what about temporary functions?
--
Martijn van Oosterhout <kl*****@svana. org> http://svana.org/kleptog/

(... have gone from d-i being barely usable even by its developers
anywhere, to being about 20% done. Sweet. And the last 80% usually takes
20% of the time, too, right?) -- Anthony Towns, debian-devel-announce

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAKWatY5T wig3Ge+YRAmMoAK DHapDC20edFd9xh ss9K5SJ1fnUzACZ AaQo
r+9fYtLgTlivGLn yfuNEOP4=
=JLwn
-----END PGP SIGNATURE-----

[Tom Lane]

Martijn van Oosterhout <kl*****@svana. org> writes:

Currently you can create temporary tables that are deleted at the end of the
session. But how about temporary views? It's just a table with a rule so I
don't imagine it would be terribly difficult. Are there any issues I havn't
thought of? While we're at it, what about temporary functions?

AFAICS, anything created in the temp schema will get zapped at backend
shutdown. (It would be a good idea to rename RemoveTempRelat ions and
related functions in namespace.c if they are going to be used to zap
other sorts of objects, but they will work as-is.)

So this is doable with just a Small Matter of Programming to pass the
is-temp flag through from the grammar to wherever the object gets
created.

Whether it's worth the trouble is another question. What's the
use-case?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

[Martijn van Oosterhout]

On Wed, Feb 11, 2004 at 12:10:29AM -0500, Tom Lane wrote:

Martijn van Oosterhout <kl*****@svana. org> writes:

Currently you can create temporary tables that are deleted at the end of the
session. But how about temporary views? It's just a table with a rule so I
don't imagine it would be terribly difficult. Are there any issues I havn't
thought of?

While we're at it, what about temporary functions?

AFAICS, anything created in the temp schema will get zapped at backend
shutdown. (It would be a good idea to rename RemoveTempRelat ions and
related functions in namespace.c if they are going to be used to zap
other sorts of objects, but they will work as-is.)

So this is doable with just a Small Matter of Programming to pass the
is-temp flag through from the grammar to wherever the object gets
created.

Well, the rules should disappear with the table, so I guess everything
should be fine in that respect.
Whether it's worth the trouble is another question. What's the
use-case?
Oh, I have a script which executes lots of queries which use several similar
rather complicated subqueries. By encapsulating these subqueries into views
all these queries could be simplified. The subqueries are not identical
between runs, though they are the same within a run.

The subqueries are not used elsewhere in the system and I'd feel better if
the definitions were near the code that used them rather than permanently in
the database where they are just clutter.

The workaround ofcourse is to do:

DROP VIEW x; -- might error
CREATE VIEW x AS ...

.... run script ...

DROP VIEW x;

and just hope no-one use the same view/table name elsewhere. It just
occurred to me that this is precisely the problem temp tables solve.

Essentially I'm using views for macro expansion.

Think it's worth it?
--
Martijn van Oosterhout <kl*****@svana. org> http://svana.org/kleptog/ (... have gone from d-i being barely usable even by its developers
anywhere, to being about 20% done. Sweet. And the last 80% usually takes
20% of the time, too, right?) -- Anthony Towns, debian-devel-announce

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAKb4MY5T wig3Ge+YRAvUWAK DJVXyjOcIyrRM2v bQ32T4687txuwCg p/vw
Nd6ZT17Ehqmbb3i fvHAitwM=
=00Ix
-----END PGP SIGNATURE-----

[Tom Lane]

Martijn van Oosterhout <kl*****@svana. org> writes:

On Wed, Feb 11, 2004 at 12:10:29AM -0500, Tom Lane wrote:

So this is doable with just a Small Matter of Programming to pass the
is-temp flag through from the grammar to wherever the object gets
created.
...
Whether it's worth the trouble is another question. What's the
use-case?

[ example snipped ]
Essentially I'm using views for macro expansion. Think it's worth it?

If you want to submit a patch I won't stand in your way. How bad is
your itch?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

[Christopher Browne]

The world rejoiced as tg*@sss.pgh.pa. us (Tom Lane) wrote:

Martijn van Oosterhout <kl*****@svana. org> writes:

Currently you can create temporary tables that are deleted at the
end of the session. But how about temporary views? It's just a
table with a rule so I don't imagine it would be terribly
difficult. Are there any issues I havn't thought of?

While we're at it, what about temporary functions?

AFAICS, anything created in the temp schema will get zapped at
backend shutdown. (It would be a good idea to rename
RemoveTempRelat ions and related functions in namespace.c if they are
going to be used to zap other sorts of objects, but they will work
as-is.)

So this is doable with just a Small Matter of Programming to pass
the is-temp flag through from the grammar to wherever the object
gets created.

Whether it's worth the trouble is another question. What's the
use-case?

It's where you create a temporary table to store some results, but
then want to create a view on top of that, because that makes some
funky self-join more convenient.

I found myself wanting this very thing last night when generating a
report. (Believe it or not!)
--
"cbbrowne","@", "ntlug.org"
http://www3.sympatico.ca/cbbrowne/spreadsheets.html
"It seems that perfection is attained not when nothing is left to add,
but when nothing is left to be taken away."
-- Antoine de Saint-Exupery.

[Arthur Ward]

>> While we're at it, what about temporary functions?
....

Whether it's worth the trouble is another question. What's the
use-case?

I have a data-loading script that transforms data from an intermediate
form in work tables to its final resting place in production. Part of this
is a major string processing step that's pushed into a stored procedure
temporarily to eliminate something on the order of a million round-trips
in trivial query overhead every night. (For each of ~320,000 records,
split a string into individual items and synchronize the detail table;
repeat for four sets of input data.)

I don't find lack of temporary functions to be a hindrance. Perhaps it's a
nice double-check for cleaning up when something goes wrong, but in that
case, I'm likely to want things left behind for debugging, but the
function creation is probably going to be rolled back anyhow.

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Martijn van Oosterhout]

On Wed, Feb 11, 2004 at 09:47:54AM -0600, Arthur Ward wrote:

While we're at it, what about temporary functions?

...

Whether it's worth the trouble is another question. What's the
use-case?

...

I don't find lack of temporary functions to be a hindrance. Perhaps it's a
nice double-check for cleaning up when something goes wrong, but in that
case, I'm likely to want things left behind for debugging, but the
function creation is probably going to be rolled back anyhow.

<Light goes on> Of course, all in one transaction. VIEW deleted on rollback
anyway.

You're right, rollback applies to anything, so this is not a really big
deal.
--
Martijn van Oosterhout <kl*****@svana. org> http://svana.org/kleptog/ (... have gone from d-i being barely usable even by its developers
anywhere, to being about 20% done. Sweet. And the last 80% usually takes
20% of the time, too, right?) -- Anthony Towns, debian-devel-announce

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAKo6wY5T wig3Ge+YRAtJ5AK CZncDXbBzloY7Xi tAbbl/U092nJgCfZDGB
jskJkJ9bV3Fl0s8 SHrhux8I=
=Yk9t
-----END PGP SIGNATURE-----

[Tom Lane]

Christopher Browne <cb******@acm.o rg> writes:

Whether it's worth the trouble is another question. What's the
use-case?

It's where you create a temporary table to store some results, but
then want to create a view on top of that, because that makes some
funky self-join more convenient. I found myself wanting this very thing last night when generating a
report. (Believe it or not!)

Hmm. Interestingly enough, you can do that right now (in 7.3 or later):

regression=# create temp table foo as select * from int8_tbl;
SELECT
regression=# create view v as select * from foo;
CREATE VIEW
regression=# \c -
You are now connected to database "regression ".
regression=# \dv v
No matching relations found.

The view goes away at backend exit because it has a dependency on foo.

Whether this is really desirable or not, I'm not sure. It would
probably be better if you'd had to say "create temp table v", just
to avoid surprises.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Bruce Momjian]

Tom Lane wrote:

Christopher Browne <cb******@acm.o rg> writes:

Whether it's worth the trouble is another question. What's the
use-case?

It's where you create a temporary table to store some results, but
then want to create a view on top of that, because that makes some
funky self-join more convenient.

I found myself wanting this very thing last night when generating a
report. (Believe it or not!)

Hmm. Interestingly enough, you can do that right now (in 7.3 or later):

regression=# create temp table foo as select * from int8_tbl;
SELECT
regression=# create view v as select * from foo;
CREATE VIEW
regression=# \c -
You are now connected to database "regression ".
regression=# \dv v
No matching relations found.

The view goes away at backend exit because it has a dependency on foo.

Whether this is really desirable or not, I'm not sure. It would
probably be better if you'd had to say "create temp table v", just
to avoid surprises.

TODO has:

* Have views on temporary tables exist in the temporary
namespace

One thing we don't have is the ability to create a temp view on a real
table, which we don't support right now.

I have added this to TODO:

* Allow temporary views on non-temporary tables

--
Bruce Momjian | http://candle.pha.pa.us
pg***@candle.ph a.pa.us | [phone]
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings