From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: More schema queries |
Date: | 2002-05-21 19:31:05 |
Message-ID: | 26855.1022009465@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> writes:
>> I'm still interested in why explicitly saying "create view
>> pg_catalog.foo" didn't work ...
> I've just been playing with this as you suggested, and using an initdb
> with both 'create view foo' and 'create view pg_catalog.bar', with the
> -- style switch I get (for both types of view):
> namespace_search_path = $user,public
> newRelation->schemaname = null
> namespaceId = 2200 (public)
> So I guess the problem is a combination of the getopt() that we've
> already found, and schemaname being null in the newRelation structure.
Given that getopt wasn't working, I'd expect namespace_search_path to be
that, and since there won't be any $user view at initdb time, public
should be the default creation target. For "create view foo",
newRelation->schemaname *should* be null and thus public would be
selected. But if you say "create view pg_catalog.foo" then
newRelation->schemaname should be "pg_catalog". Can you trace it back a
little further and try to see why it's not? It works fine here AFAICT,
so I'm wondering about portability problems ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Lamar Owen | 2002-05-21 19:44:40 | Re: Redhat 7.3 time manipulation bug |
Previous Message | Dave Page | 2002-05-21 19:24:46 | Re: More schema queries |