Re: [COMMITTERS] pgsql: Sequences were not being shown due to the use of lowercase `s` - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Re: [COMMITTERS] pgsql: Sequences were not being shown due to the use of lowercase `s`
Date
Msg-id ae520f542bae55005bc660d8ecb84a41@biglumber.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Sequences were not being shown due to the use of lowercase `s`  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses information_schema vs temp tables (was Re: [COMMITTERS] pgsql: Sequences were not being shown due to the use of lowercase `s`)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Tom Lane asked:
> Superusers can access anything they want to.  What's your point?
> The spec says "accessible" ...

<disclaimer>
Not trying to lecture you Tom :), just posting my argument
here for others.
</disclaimer>

Temp tables are "special" because the user does not know (and,
more importantly, should not usually have to know) which
pg_temp_ schema the table is created in. For example, if I am
in session #1 and create a table, I simply issue

CREATE TABLE foobar(a int);

If I want to test for the table's existence, I simply do:

SELECT 1 FROM information_schema.tables
WHERE table_name ='foobar';

If I want to be more specific with regards to a schema:

CREATE TABLE zoo.foobar(a int);

SELECT 1 FROM information_schema.tables
WHERE table_name ='foobar' AND table_schema = 'zoo';

However, if I create a temp table, a problem occurs:

CREATE TEMP TABLE foobar(a int);

SELECT 1 FROM information_schema.tables
WHERE table_name ='foobar'; -- which schema?

The above might give a false positive if another session has
created a temporary table of that name. Since the whole point of
temp tables is temporary per-session relations, it seems silly
for information_schema to tell me that another session already
has a temporary table by that name, since that information has
no use to me whatsoever. I cannot read from the other temp table
(which could be a strong "non-accessible" argument), and its
existence won't stop me from creating a same-named temporary table
in my own session. The only thing it can do is cause errors for
people who think that there is already a temporary table by that
name and try to drop it (which is what prompted this patch in
the first place).

I can't think of a use case where a user would not want to
append a "is_visible" clause to the query above. That or start
tracking which pg_temp_ schema belongs to whom.

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation
PGP Key: 0x14964AC8 200609061927
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFE/1unvJuQZxSWSsgRAgC3AJ4kNmy2DMdGcZmsnbfAkODahKIgTACg9q2I
+5q4E6BDmU87o28DnG5QZ1s=
=4GFl
-----END PGP SIGNATURE-----




pgsql-hackers by date:

Previous
From: Chris Browne
Date:
Subject: Re: New Linux Filesystem: NILFS
Next
From: Bruce Momjian
Date:
Subject: Re: New XML section for documentation