Bruce Momjian <[EMAIL PROTECTED]> writes:
> If I remove public create access to public, can the super user or db
> owner still create tables?
Superusers can always do whatever they want.
The DB owner (assume he's not a superuser) has no special privileges
w.r.t. the public schema at the moment.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I don't have a better idea, but I am wondering how this will work. If I
> > create a schema with my name, does it get added to the front of my
> > schema schema search path automatically,
>
> Yes (unless you've futzed with the stand
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't have a better idea, but I am wondering how this will work. If I
> create a schema with my name, does it get added to the front of my
> schema schema search path automatically,
Yes (unless you've futzed with the standard value of search_path).
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am a little uncomfortable about this. It means that CREATE TABLE will
> > create a table in 'public' if the user doesn't have a schema of their
> > own, and in their private schema if it exists. I seems strange to have
> > such a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am a little uncomfortable about this. It means that CREATE TABLE will
> create a table in 'public' if the user doesn't have a schema of their
> own, and in their private schema if it exists. I seems strange to have
> such a distinction based on wheth
Tom Lane wrote:
> If you don't create schemas then you get backwards-compatible behavior
> (all the users end up sharing the "public" schema as their current
> schema).
I am a little uncomfortable about this. It means that CREATE TABLE will
create a table in 'public' if the user doesn't have a s
Ian Barwick <[EMAIL PROTECTED]> writes:
> CREATE OR REPLACE FUNCTION public.first_visible_namespace(name)
> RETURNS oid
> AS
> 'SELECT n.oid
> FROM pg_namespace n, pg_class c, public.current_schemas_setof() cs
> WHERE c.relname=3D $1
> AND c.relnamespace=3Dn.oid
> AND
On Wednesday 01 May 2002 06:38, Tom Lane wrote:
> Ian Barwick <[EMAIL PROTECTED]> writes:
> > How can I restrict the query to the schemas in the
> > current search path, i.e. the schema names returned
> > by SELECT current_schemas() ?
>
> Well, this is the issue open for public discussion.
>
> We
Tom Lane wrote:
> bar were in my search path, so I should not see them unless I give a
> qualified name (eg, "\d foo.mytab" or "\d bar.mytab"). For commands
> that accept wildcard patterns, what should happen --- should "\z my*"
> find these tables, if they're not in my search path? Is "\z f*.my
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> I see there are routines doing similar things but for functions and
> others. I'm right in saying that OID isn't unique in a database
> (necessarily) and so we couldn't have a general object_is_visible(oid)
> function that did the appropiate from th
On Mon, 6 May 2002, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > For this if we look once again at RelnameGetRelid(relname) in
> > backend/catalog/namespace.c wouldn't this is_visible() function simply be a
> > wrapper around it?
>
> Sort of. It's there already, see Rela
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> For this if we look once again at RelnameGetRelid(relname) in
> backend/catalog/namespace.c wouldn't this is_visible() function simply be a
> wrapper around it?
Sort of. It's there already, see RelationIsVisible.
regards,
On Mon, 6 May 2002, Nigel J. Andrews wrote:
>
> On Mon, 6 May 2002, Tom Lane wrote:
>
> > "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > > Coming back to this subject if I may but only briefly, I hope. How
> > > about making a slight change to current_schemas() and including an
> > > optiona
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> I also got it wrong about when the temporary space is emptied. I had been
> thinking it was when the connection terminated. However, I see from the same
> old message that this happens when the first temporary item is created in a
> session. Therefo
On Mon, 6 May 2002, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > Coming back to this subject if I may but only briefly, I hope. How
> > about making a slight change to current_schemas() and including an
> > optional argument such that something like:
> > current_schemas(
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> Coming back to this subject if I may but only briefly, I hope. How
> about making a slight change to current_schemas() and including an
> optional argument such that something like:
> current_schemas(1)
> returns the complete list of schemas in the
Re: BackendID and the schema search path
Coming back to this subject if I may but only briefly, I hope. How about making
a slight change to current_schemas() and including an optional argument such
that something like:
current_schemas(1)
returns the complete list of schemas in the search pat
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Thu, 2002-05-02 at 16:52, Tom Lane wrote:
>> If we used PID then we'd eventually have 64K (or whatever the range of
>> PIDs is on your platform) different pg_temp_nnn entries cluttering
>> pg_namespace.
> Should they not be cleaned up at backend exit
On Thu, 2002-05-02 at 16:52, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Is "PROC array slot number" something internal to postgres ?
>
> Yes.
>
> If we used PID then we'd eventually have 64K (or whatever the range of
> PIDs is on your platform) different pg_temp_nnn entries
Ian Barwick <[EMAIL PROTECTED]> writes:
> i.e. user "joe" can see which objects exist in schema "foo2", even though
> he has no USAGE privilege. (Is this behaviour intended?)
It's open for debate I suppose. Historically we have not worried about
preventing people from looking into the system tab
On Thu, May 02, 2002 at 05:28:36PM +0300, Oleg Bartunov wrote:
> On Wed, 1 May 2002, Jeffrey W. Baker wrote:
>
> > On Tue, Apr 30, 2002 at 09:41:47PM +0300, Oleg Bartunov wrote:
> > > I think DBD::Pg driver very much depends on system tables.
> > > Hope, Jeffrey (current maintainer) is online.
>
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Is "PROC array slot number" something internal to postgres ?
Yes.
If we used PID then we'd eventually have 64K (or whatever the range of
PIDs is on your platform) different pg_temp_nnn entries cluttering
pg_namespace. But we only need MaxBackends diff
On Wed, 1 May 2002, Jeffrey W. Baker wrote:
>> These changes may break DBD::Pg. What is the expected
>> time of this release? I will review my code for impact.
I think the current plan is to go beta in late summer. So there's
no tremendous hurry. I was just sending out a wake-up call ...
On Wed, 1 May 2002, Jeffrey W. Baker wrote:
> On Tue, Apr 30, 2002 at 09:41:47PM +0300, Oleg Bartunov wrote:
> > I think DBD::Pg driver very much depends on system tables.
> > Hope, Jeffrey (current maintainer) is online.
>
> These changes may break DBD::Pg. What is the expected
> time of this r
On Thu, 2002-05-02 at 15:48, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > On Thu, 2002-05-02 at 05:33, Tom Lane wrote:
> >> The temp schema is pg_temp_nnn where nnn is your BackendId (PROC array
> >> slot number). AFAIK there isn't any exported way to determine your
> >> Backen
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Thu, 2002-05-02 at 05:33, Tom Lane wrote:
>> The temp schema is pg_temp_nnn where nnn is your BackendId (PROC array
>> slot number). AFAIK there isn't any exported way to determine your
>> BackendId from an SQL query.
> The non-portable way on Linux
On Thursday 02 May 2002 05:33, Tom Lane wrote:
[on establishing whether a relation is in the search path]
> This doesn't yield much insight about cases where the match pattern
> includes a (partial?) schema-name specification, though. If I'm
> allowed to write something like "\z s*.t*" to find t
On Tue, Apr 30, 2002 at 09:41:47PM +0300, Oleg Bartunov wrote:
> I think DBD::Pg driver very much depends on system tables.
> Hope, Jeffrey (current maintainer) is online.
These changes may break DBD::Pg. What is the expected
time of this release? I will review my code for impact.
Thanks for t
On Thu, 2002-05-02 at 05:33, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > So, how does one determine the current schema for temporary tables,
> > i.e. what name would be in search_path if it wasn't implicitly included?
>
> The temp schema is pg_temp_nnn where nnn is your B
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> So, how does one determine the current schema for temporary tables,
> i.e. what name would be in search_path if it wasn't implicitly included?
The temp schema is pg_temp_nnn where nnn is your BackendId (PROC array
slot number). AFAIK there isn't a
On Thu, 2 May 2002, Ian Barwick wrote:
> Tom Lane wrote:
> [snipped]
> > My gut feeling is that "\d mytab" should tell you about the same
> > table that "select * from mytab" would find. Anything else is
> > probably noise to you --
>
> General consistency with SELECT behaviour sounds right to
Tom Lane wrote:
> psql's \d command hasn't the foggiest idea that there might now be more
> than one pg_class entry with the same relname. It needs to be taught
> about that --- but even before that, we need to work out schema-aware
> definitions of the wildcard expansion rules for psql's backsla
Ian Barwick <[EMAIL PROTECTED]> writes:
> How can I restrict the query to the schemas in the
> current search path, i.e. the schema names returned
> by SELECT current_schemas() ?
Well, this is the issue open for public discussion.
We could define some function along the lines of
"is_visible_tab
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> What about "CREATE USER tgl WITH SCHEMA;" ?
Uh, what about it? It's not a standard syntax AFAIK.
If I were running an installation where I wanted "one schema per user"
as default, I'd rather have an "auto_create_schema" SET parameter that
> produces a result like this:
>
> schema | object
> +
> public | abc
> foo| abc
> foo| xyz
> bar| xyz
> (4 rows)
>
> How can I restrict the query to the schemas in the
> current search path, i.e. the schema names returned
> by SELECT current_schemas() ?
Now, if w
> test=# CREATE USER tgl;
> CREATE USER
> test=# CREATE SCHEMA tgl AUTHORIZATION tgl;
> CREATE
What about "CREATE USER tgl WITH SCHEMA;" ?
Which will implicitly do a "CREATE SCHEMA tgl AUTHORIZATION tgl;"
Chris
---(end of broadcast)---
TIP 1: s
> For commands
> that accept wildcard patterns, what should happen --- should "\z my*"
> find these tables, if they're not in my search path? Is "\z f*.my*"
> sensible to support? I dunno yet.
Technical question - this query:
SELECT nspname AS schema,
relname AS object
FRO
Bill Cunningham <[EMAIL PROTECTED]> writes:
> So we now have a default schema name of the current user?
> ... This is exactly how DB2 operates, implict schemas for each user.
You can operate that way. It's not the default though; the DBA will
have to explicitly do a CREATE SCHEMA for each user.
Tom Lane wrote:
>Bill Cunningham <[EMAIL PROTECTED]> writes:
>
>>I would think this should produce the following:
>>
>
>>test=# \d mytab
>>Table "bar.mytab"
>> Column | Type | Modifiers
>>+-+---
>> f1 | text|
>> f1 | integer |
>>
>
>>Table "f
I think DBD::Pg driver very much depends on system tables.
Hope, Jeffrey (current maintainer) is online.
regards,
Oleg
On Tue, 30 Apr 2002, Tom Lane wrote:
> Current CVS tip has most of the needed infrastructure for SQL-spec
> schema support: you can create schemas, and
Bill Cunningham <[EMAIL PROTECTED]> writes:
> I would think this should produce the following:
> test=# \d mytab
> Table "bar.mytab"
> Column | Type | Modifiers
> +-+---
> f1 | text|
> f1 | integer |
> Table "foo.mytab"
> Column | Type
>
>Here's an example of what's broken:
>
>test=# create schema foo;
>CREATE
>test=# create table foo.mytab (f1 int, f2 text);
>CREATE
>test=# create schema bar;
>CREATE
>test=# create table bar.mytab (f1 text, f3 int);
>CREATE
>test=# \d mytab
>Table "mytab"
> Column | Type | Modifier
Current CVS tip has most of the needed infrastructure for SQL-spec
schema support: you can create schemas, and you can create objects
within schemas, and search-path-based lookup for named objects works.
There's still a number of things to be done in the backend, but it's
time to start working on
43 matches
Mail list logo
