Temporary views

**Tom Lane** · Nov 22 '05, 08:57 AM

Re: Temporary views

Martijn van Oosterhout <kleptog@svana. org> writes:[color=blue]
> 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?[/color]
[color=blue]
> While we're at it, what about temporary functions?[/color]

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 majordomo@postg resql.org)

**Martijn van Oosterhout** · Nov 22 '05, 08:57 AM

Re: Temporary views

On Wed, Feb 11, 2004 at 12:10:29AM -0500, Tom Lane wrote:[color=blue]
> Martijn van Oosterhout <kleptog@svana. org> writes:[color=green]
> > 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?[/color]
> [color=green]
> > While we're at it, what about temporary functions?[/color]
>
> 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.[/color]

Well, the rules should disappear with the table, so I guess everything
should be fine in that respect.
[color=blue]
> Whether it's worth the trouble is another question. What's the
> use-case?[/color]

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/[color=blue]
> (... 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[/color]

-----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** · Nov 22 '05, 08:57 AM

Re: Temporary views

Martijn van Oosterhout <kleptog@svana. org> writes:[color=blue]
> On Wed, Feb 11, 2004 at 12:10:29AM -0500, Tom Lane wrote:[color=green]
>> 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?[/color][/color]
[color=blue]
> [ example snipped ]
> Essentially I'm using views for macro expansion.[/color]
[color=blue]
> Think it's worth it?[/color]

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 majordomo@postg resql.org so that your
message can get through to the mailing list cleanly

**Christopher Browne** · Nov 22 '05, 08:57 AM

Re: Temporary views

The world rejoiced as tgl@sss.pgh.pa. us (Tom Lane) wrote:[color=blue]
> Martijn van Oosterhout <kleptog@svana. org> writes:[color=green]
>> 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?[/color]
>[color=green]
>> While we're at it, what about temporary functions?[/color]
>
> 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?[/color]

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** · Nov 22 '05, 08:57 AM

Re: Temporary views

>> While we're at it, what about temporary functions?
....[color=blue]
> Whether it's worth the trouble is another question. What's the
> use-case?[/color]

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** · Nov 22 '05, 08:58 AM

Re: Temporary views

On Wed, Feb 11, 2004 at 09:47:54AM -0600, Arthur Ward wrote:[color=blue][color=green][color=darkred]
> >> While we're at it, what about temporary functions?[/color][/color]
> ...[color=green]
> > Whether it's worth the trouble is another question. What's the
> > use-case?[/color]
>
> ...
>
> 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.[/color]

<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/[color=blue]
> (... 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[/color]

-----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** · Nov 22 '05, 08:59 AM

Re: Temporary views

Christopher Browne <cbbrowne@acm.o rg> writes:[color=blue][color=green]
>> Whether it's worth the trouble is another question. What's the
>> use-case?[/color][/color]
[color=blue]
> 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.[/color]
[color=blue]
> I found myself wanting this very thing last night when generating a
> report. (Believe it or not!)[/color]

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** · Nov 22 '05, 08:59 AM

Re: Temporary views

Tom Lane wrote:[color=blue]
> Christopher Browne <cbbrowne@acm.o rg> writes:[color=green][color=darkred]
> >> Whether it's worth the trouble is another question. What's the
> >> use-case?[/color][/color]
>[color=green]
> > 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.[/color]
>[color=green]
> > I found myself wanting this very thing last night when generating a
> > report. (Believe it or not!)[/color]
>
> 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.[/color]

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.ph a.pa.us | (610) 359-1001
+ 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