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
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 whether a
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 could define
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 n.oid=3D
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*
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
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 the type
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 search
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(1)
returns
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. Therefore, my
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
optional argument such
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, tom
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 cluttering
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 even
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 BackendId
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
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
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 RH 7.2 :
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
BackendId from an
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 ...
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
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 tables,
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.
These
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 backslash
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 me.
I take
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 any
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 | Modifiers
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
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 foo.mytab
Column | Type |
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.
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:
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 we had
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
told
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
34 matches
Mail list logo
