On Wed, Feb 18, 2009 at 10:44:27AM +0100, Ivan Sergio Borgonovo wrote:
> It looks like I may put myself in a situation where I may get
> trapped by insidious bugs related to the order in which the schema
> path is read.
>
> I think I prefer to spend some time qualifying the schema in the
> functio
On Tue, 17 Feb 2009 22:11:03 -0700
Scott Marlowe wrote:
> This is incorrect. As long as both tables are in your search path
> it will work just fine. But you do have to re-connect to flush
> your cached plans for the functions.
That was the missing part.
It seems the trick is going to be the s
On Tue, Feb 17, 2009 at 8:42 PM, Schwaighofer Clemens
wrote:
> On Wed, Feb 18, 2009 at 07:31, Ivan Sergio Borgonovo
> wrote:
>> alter table y set schema new_schema;
>>
>> test=# SELECT * from x();
>> ERROR: relation "y" does not exist
>> CONTEXT: SQL statement " select a,b from x join y on x.xi
On Wed, Feb 18, 2009 at 07:31, Ivan Sergio Borgonovo
wrote:
> alter table y set schema new_schema;
>
> test=# SELECT * from x();
> ERROR: relation "y" does not exist
> CONTEXT: SQL statement " select a,b from x join y on x.xid=y.xid"
> PL/pgSQL function "x" line 2 at RETURN QUERY
> test=# SELECT
On Tue, Feb 17, 2009 at 3:31 PM, Ivan Sergio Borgonovo
wrote:
> On Tue, 17 Feb 2009 17:36:32 +
> Sam Mason wrote:
>
>> On Tue, Feb 17, 2009 at 06:20:54PM +0100, Ivan Sergio Borgonovo
>> wrote:
>> > I can't get how this really work.
>> > You're saying that constraint, fk/pk relationships will
On Tue, 17 Feb 2009 17:36:32 +
Sam Mason wrote:
> On Tue, Feb 17, 2009 at 06:20:54PM +0100, Ivan Sergio Borgonovo
> wrote:
> > I can't get how this really work.
> > You're saying that constraint, fk/pk relationships will be
> > preserved automatically... what else?
> >
> > OK BEFORE:
> >
>
On Tue, Feb 17, 2009 at 06:20:54PM +0100, Ivan Sergio Borgonovo wrote:
> I can't get how this really work.
> You're saying that constraint, fk/pk relationships will be preserved
> automatically... what else?
>
> OK BEFORE:
>
> create table x (
> xid primary key,
> ...
> );
> create table y (
>
On Tue, 17 Feb 2009 12:19:14 +
Sam Mason wrote:
> > > I'd like to move all the 200 tables to a new schema and leave
> > > that one in the public schema.
> >
> > ALTER TABLE name SET SCHEMA new_schema;
>
> Make sure your functions don't contain any hard coded references to
> the old schema
On Tue, Feb 17, 2009 at 01:09:10AM -0700, Scott Marlowe wrote:
> On Tue, Feb 17, 2009 at 12:34 AM, Ivan Sergio Borgonovo
> wrote:
> > I've around 150-200 tables in the same schema.
> > Some of them have pk/fk relationships and are referenced into
> > functions (~20).
> >
> > I'd like to move all t
On 17/02/2009 08:09, Scott Marlowe wrote:
> ALTER TABLE name SET SCHEMA new_schema;
And you can do this for all your tables inside a transaction, making it
an all-or-nothing operation. :-)
Ray.
--
Raymond O'Donnell, Director of Mus
On Tue, Feb 17, 2009 at 12:34 AM, Ivan Sergio Borgonovo
wrote:
> I've around 150-200 tables in the same schema.
> Some of them have pk/fk relationships and are referenced into
> functions (~20).
>
> One of them is surely referenced by most of those 20 and it is the
> largest.
>
> I'd like to move
I've around 150-200 tables in the same schema.
Some of them have pk/fk relationships and are referenced into
functions (~20).
One of them is surely referenced by most of those 20 and it is the
largest.
I'd like to move all the 200 tables to a new schema and leave that
one in the public schema.
T
12 matches
Mail list logo
