Temporary views

Martijn van Oosterhout <kleptog@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 RemoveTempRelations 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

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

Martijn van Oosterhout <kleptog@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 RemoveTempRelations 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 <kleptog@svana.org> http://svana.org/kleptog/

Martijn van Oosterhout <kleptog@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

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

Martijn van Oosterhout <kleptog@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
RemoveTempRelations 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.

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.

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 <kleptog@svana.org> http://svana.org/kleptog/

Christopher Browne <cbbrowne@acm.org> 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

Tom Lane wrote:

Christopher Browne <cbbrowne@acm.org> 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
  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