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

Fwd: Re: ALTER OBJECT any_name SET SCHEMA name

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Fwd: Re: ALTER OBJECT any_name SET SCHEMA name
Date: 2010-11-03 17:15:39
Message-ID: 1288804459-sup-6627@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Sorry, I messed up and emailed this only to Dimitri.


--- Begin forwarded message from Alvaro Herrera ---
From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Date: Wed, 03 Nov 2010 14:13:58 -0300
Subject: Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Excerpts from Dimitri Fontaine's message of mié nov 03 13:10:12 -0300 2010:

> Then, I think the ALTER EXTENSION foo SET SCHEMA name still has a use
> case, so I've prepared a simple patch to show the API usage before we
> get to refactor it all following Tom's asking. So there's a initial
> patch to see that in action. I had to rework AlterFunctionNamespace()
> API so that I can call it from elsewhere in the backend where I have
> Oids, so here's an updated set_schema.4.patch. We will have to extend
> the APIs for relations and types the same way, but it's already possible
> to test the patch with some extensions this way.

Before I noticed that you were going to rework this patch completely, I
cleaned it up a bit; attached (probably just for your amusement)

I was looking at this patch 'cause someone asked for the ability to do
CREATE TEMP <OBJECT> for objects that currently don't support it.  I
thought this might be related.

--- End forwarded message ---

-- 
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>

Attachment: 0010-Clean-up-ALTER-OBJECT-SET-SCHEMA-patch.patch
Description: application/octet-stream (14.4 KB)

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-11-03 18:03:18
Subject: Re: Improving planner's handling of min/max aggregate optimization
Previous:From: Tom LaneDate: 2010-11-03 16:28:42
Subject: Re: why does plperl cache functions using just a bool for is_trigger

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