Skip site navigation (1) Skip section navigation (2)

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

From: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Sequences were not being shown due to the use of lowercase `s`
Date: 2006-09-06 23:40:07
Message-ID: ae520f542bae55005bc660d8ecb84a41@biglumber.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-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(at)turnstep(dot)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-----



In response to

Responses

pgsql-hackers by date

Next:From: Jeff DavisDate: 2006-09-06 23:58:36
Subject: Re: New Linux Filesystem: NILFS
Previous:From: Chris BrowneDate: 2006-09-06 22:55:24
Subject: Re: New Linux Filesystem: NILFS

pgsql-committers by date

Next:From: Bruce MomjianDate: 2006-09-07 00:04:49
Subject: pgsql: Add XML documentation.
Previous:From: User Mario__Date: 2006-09-06 22:10:28
Subject: webtranslator - l10n: Now I'm using RequestContest, that way I can use

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group