Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Sat, Nov 27, 2010 at 2:17 PM, Dimitri Fontaine wrote: > Thanks! > > The _oid variants will have to re-appear in the "alter extension set > schema" patch, which is the last of the series. Meanwhile, I will have > to merge head with the current extension patch (already overdue for a > new version

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Robert Haas writes: > Committed, after various changes and corrections. One noteworthy one > is that I removed the _oid variants, since those would be dead code at > the moment. Thanks! The _oid variants will have to re-appear in the "alter extension set schema" patch, which is the last of the

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Thu, Nov 25, 2010 at 5:00 PM, Dimitri Fontaine wrote: > Robert Haas writes: >> Please do.  Tab completion support should really be included in the >> patch - adding it as a separate patch is better than not having it, of >> course. > > Please find attached version 9 of the patch, which include

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Robert Haas writes: > Please do. Tab completion support should really be included in the > patch - adding it as a separate patch is better than not having it, of > course. Please find attached version 9 of the patch, which includes psql completion support of the "SET SCHEMA" variant of already s

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Robert Haas writes: > Especially because you also posted some revs of the ALTER EXTENSION .. > SET SCHEMA patch on this thread Yes, I tried to answer where questions have been raised, and that's not helping so much at review time. That's why I take the time to update the commit fest applicati

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Sun, Nov 21, 2010 at 4:47 PM, Dimitri Fontaine wrote: > Robert Haas writes: >> On Sat, Nov 20, 2010 at 11:23 PM, Robert Haas wrote: >>> Ah, nuts.  I see now there's a v7.  Never mind... >> >> OK.  I looked at the right version, now.  Hopefully. > > Yeah, that was the most recent one and I lin

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Robert Haas writes: > On Sat, Nov 20, 2010 at 11:23 PM, Robert Haas wrote: >> Ah, nuts.  I see now there's a v7.  Never mind... > > OK. I looked at the right version, now. Hopefully. Yeah, that was the most recent one and I linked it in the commit fest application. Given the very fast feedback

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Robert Haas writes: > So, attached is a proposed patch that just adds CheckSetNamespace() > and makes the existing SET SCHEMA commands use it. Barring > objections, I'll go ahead and commit this part. Thank you for applying the new function to the existing code paths, that was needed as soon as

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Nov 21, 2010, at 1:03 PM, David Fetter wrote: > Should this really error out? It's just a NOOP, so perhaps a NOTICE > would be more appropriate. Perhaps, but the purpose of this patch is to streamline the code, not change the behavior. ...Robert -- Sent via pgsql-hackers mailing list (pgsq

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Sun, Nov 21, 2010 at 07:53:57AM -0500, Robert Haas wrote: > On Sat, Nov 20, 2010 at 11:23 PM, Robert Haas wrote: > > Ah, nuts.  I see now there's a v7.  Never mind... > > OK. I looked at the right version, now. Hopefully. > > It seems we have no regression tests at all for any of the existi

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Sat, Nov 20, 2010 at 11:23 PM, Robert Haas wrote: > Ah, nuts.  I see now there's a v7.  Never mind... OK. I looked at the right version, now. Hopefully. It seems we have no regression tests at all for any of the existing SET SCHEMA commands. This seems like a good time to correct that over

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Sat, Nov 20, 2010 at 11:22 PM, Robert Haas wrote: > On Thu, Nov 4, 2010 at 3:39 PM, Dimitri Fontaine > wrote: >> Tom Lane writes: >>> Not having read the patch, but ... the idea that was in the back of >>> my mind was to have a generic AlterObjectNamespace function that >>> would take parame

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Thu, Nov 4, 2010 at 3:39 PM, Dimitri Fontaine wrote: > Tom Lane writes: >> Not having read the patch, but ... the idea that was in the back of >> my mind was to have a generic AlterObjectNamespace function that >> would take parameters approximately like the following: > > Please find attached

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Alvaro Herrera writes: > Basically you're saying that the owner of the schema in which the > extension is installed can drop the extension ... even though, according > to your previous argument, the extension is not "in" said schema :-) Yeah it's a case of defining things. The extension is not in

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Excerpts from Dimitri Fontaine's message of vie nov 05 16:58:00 -0300 2010: > dim=> drop schema bob cascade; > NOTICE: drop cascades to extension unaccent > DROP SCHEMA > > dim=> \c - dim > You are now connected to database "dim" as user "dim". > dim=# select installed from pg_extensions where n

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Tom Lane writes: > You're mistaken, and this case definitely does need more thought. > A schema owner is presumed to have the unconditional right to > drop anything in his schema, whether he owns it or not. Here a paste of how it works with current code. dim=# create schema bob authorization bob

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Dimitri Fontaine writes: > Tom Lane writes: >> Here's another question: if an extension's objects live (mostly or >> entirely) in schema X, what happens if the possibly-unprivileged owner >> of schema X decides to drop it? If the extension itself is considered >> to live within the schema, then

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Tom Lane writes: >> Are you proposing that an extension object is schema qualified? > > Dunno, I'm just asking the question. If it isn't, why not? Because extension are much like languages for stored procedure, on the utility side rather than on the query side. The only queries that uses languag

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Dimitri Fontaine writes: > Tom Lane writes: >> BTW, I'm not even 100% convinced that the schema shouldn't be part of >> the extension's name, if we're going to make it work like this. Is >> there a reason I shouldn't be able to have both public.myextension >> and testing.myextension? If we're c

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Tom Lane writes: > I'm with Alvaro on this. If we're going to have an ALTER EXTENSION SET > SCHEMA operation, then extensions must have a well-defined schema > property, and it would be good if that connection were explicitly > represented in the catalogs. Digging stuff out of pg_depend sucks; >

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Dimitri Fontaine writes: > Alvaro Herrera writes: >> Frankly, the get_extension_namespace bit still feels wrong to me. I >> would have the namespace be present in the pg_extension catalog, even if >> it's not part of the primary key. > Well, I'm thinking that: > - namespace columns in the cata

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Alvaro Herrera writes: > Frankly, the get_extension_namespace bit still feels wrong to me. I > would have the namespace be present in the pg_extension catalog, even if > it's not part of the primary key. This would let you answer the > question: what schema did I install this extension in? (and

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Excerpts from Dimitri Fontaine's message of vie nov 05 06:49:34 -0300 2010: > Alvaro Herrera writes: > > Hmm, seeing the amount of new includes in extension.c, I wonder if it'd > > be better to move AlterExtensionNamespace to alter.c. > > It was mainly missing includes cleanup. The guts of the fu

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Alvaro Herrera writes: > Hmm, seeing the amount of new includes in extension.c, I wonder if it'd > be better to move AlterExtensionNamespace to alter.c. It was mainly missing includes cleanup. The guts of the function is now so short I can inline it in this mail: targetObjects = listDepe

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Alvaro Herrera writes: > The has_privs_of_role() call has the wrong ACL_KIND argument in the > error report. Ah yes, I missed the acl_kind. It's a parameter of the function in the v7 patch, attached. > (Nitpick: don't use "e.g." at the end of the phrase. It seems strange > to me.) Fixed too. I

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Excerpts from Dimitri Fontaine's message of jue nov 04 16:42:53 -0300 2010: > Alvaro Herrera writes: > > 2. I think the guts of AlterExtensionNamespace (the large switch block) > > should be elsewhere, probably in alter.c > > That's implemented in the alter_extension patch v2, and that's much > b

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Excerpts from Dimitri Fontaine's message of jue nov 04 16:39:31 -0300 2010: > Tom Lane writes: > > Not having read the patch, but ... the idea that was in the back of > > my mind was to have a generic AlterObjectNamespace function that > > would take parameters approximately like the following: >

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Alvaro Herrera writes: > 2. I think the guts of AlterExtensionNamespace (the large switch block) > should be elsewhere, probably in alter.c That's implemented in the alter_extension patch v2, and that's much better, thanks for your continued input. Please note that it depends on the new set_schem

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Tom Lane writes: > Not having read the patch, but ... the idea that was in the back of > my mind was to have a generic AlterObjectNamespace function that > would take parameters approximately like the following: Please find attached what I came up with, that's the set_schema patch version 6. Reg

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Excerpts from Dimitri Fontaine's message of jue nov 04 11:52:53 -0300 2010: > Alvaro Herrera writes: > > 3. Not this patch, but I think using "extension" as a global variable > > name is a bad idea. > > What about create_extension_extension instead? I'm not thinking of > something better, bikesh

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Excerpts from Dimitri Fontaine's message of jue nov 04 11:37:37 -0300 2010: > Alvaro Herrera writes: > >> /* check for duplicate name (more friendly than unique-index failure) > >> */ > >> if (SearchSysCacheExists2(TYPENAMENSP, > >> CStringGetDatum(name), > >

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Thu, Nov 4, 2010 at 8:18 AM, Dimitri Fontaine wrote: > Robert Haas writes: >> On Thu, Nov 4, 2010 at 7:52 AM, Dimitri Fontaine >> wrote: >>> What about create_extension_extension instead? I'm not thinking of >>> something better, bikeshedding is opened. >> >> That doesn't seem very clear...

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Robert Haas writes: > On Thu, Nov 4, 2010 at 7:52 AM, Dimitri Fontaine > wrote: >> What about create_extension_extension instead? I'm not thinking of >> something better, bikeshedding is opened. > > That doesn't seem very clear... I'm always suspicious of names that > use the same word twice, an

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Tom Lane writes: > Not having read the patch, but ... the idea that was in the back of > my mind was to have a generic AlterObjectNamespace function that > would take parameters approximately like the following: > > OID of catalog containing object > Column number of catalog's namespac

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Thu, Nov 4, 2010 at 7:52 AM, Dimitri Fontaine wrote: > What about create_extension_extension instead? I'm not thinking of > something better, bikeshedding is opened. That doesn't seem very clear... I'm always suspicious of names that use the same word twice, and in this case I have no idea wha

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Alvaro Herrera writes: > 1. wouldn't it make more sense to save the extension namespace in the > extension catalog? I don't think so, because the extension itself is not schema qualified. What lives in the namespace the extension depends on is not the extension itself, but its objects. > 2. I th

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Dimitri Fontaine writes: > Well, I'll go fix as you say, putting the check back into the > callers. That won't help a bit with the code duplication feeling we have > when reading the patch, though. Any idea on this front? Not having read the patch, but ... the idea that was in the back of my mind

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Excerpts from Dimitri Fontaine's message of jue nov 04 11:06:48 -0300 2010: > Also attached, please find the complete version of ALTER EXTENSION ext > SET SCHEMA name; with support for all contrib extensions. That's the > example that allows to see the API (AlterFooNamespace_oid and _internal > fu

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Alvaro Herrera writes: >> /* check for duplicate name (more friendly than unique-index failure) */ >> if (SearchSysCacheExists2(TYPENAMENSP, >> CStringGetDatum(name), >> ObjectIdGetDatum(nspOid))) > > Hmm, this check is wrong anyw

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Excerpts from Dimitri Fontaine's message of jue nov 04 11:06:48 -0300 2010: > Alvaro Herrera writes: > > FWIW I think you should use getObjectDescription, as in the attached > > patch. (Note the patch is incomplete and does not compile because only > > one caller to CheckSetNamespace has been fix

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Alvaro Herrera writes: > FWIW I think you should use getObjectDescription, as in the attached > patch. (Note the patch is incomplete and does not compile because only > one caller to CheckSetNamespace has been fixed). I had to re-add the object name to the CheckSetNamespace prototype to handle t

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Alvaro Herrera writes: > FWIW I think you should use getObjectDescription, as in the attached > patch. (Note the patch is incomplete and does not compile because only > one caller to CheckSetNamespace has been fixed). That a very good idea, will apply (cherry-pick -n) and finish it tomorrow, tha

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

Fwd: Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Sorry, I messed up and emailed this only to Dimitri. --- Begin forwarded message from Alvaro Herrera --- From: Alvaro Herrera To: Dimitri Fontaine 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 o

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Robert Haas writes: > Yeah, I think that sucks a lot. I don't see what's wrong with > Heikki's solution, actually. Coding the parser and replace. If all it takes is calling our replace function on the all-in-memory query string that we have in pg_execute_from_file() function, I can have a try at

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Sun, Oct 31, 2010 at 5:46 PM, Dimitri Fontaine wrote: > Heikki Linnakangas writes: >> Just do "SET search_pa...@extschema@" at the beginning of the install >> script, just like we have "SET search_path=public" there now. > > Well there's the installation itself then the "runtime", as you say >

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Heikki Linnakangas writes: > Just do "SET search_pa...@extschema@" at the beginning of the install > script, just like we have "SET search_path=public" there now. Well there's the installation itself then the "runtime", as you say later... > Well, in case of functions you can always do "CREATE F

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On 31.10.2010 21:42, Dimitri Fontaine wrote: Heikki Linnakangas writes: If I understand that correctly, the idea is that p_fun holds the name of a function that's in the same schema as the extension? You would write that as v_sql := 'SELECT * FROM @extsch...@.' || p_fun || '()'; Fair enough.

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Heikki Linnakangas writes: > If I understand that correctly, the idea is that p_fun holds the name of a > function that's in the same schema as the extension? You would write that as > > v_sql := 'SELECT * FROM @extsch...@.' || p_fun || '()'; Fair enough. Now what about the citext example, where

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Robert Haas writes: ... > related indexes, sequences, and constraints. It seems hard to fit > that into a general framework, but maybe it could be done for other > object types. My guess is that we're talking about having a generic code that would get exercised directly from src/backend/commands

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On 31.10.2010 20:19, Dimitri Fontaine wrote: Heikki Linnakangas writes: In particular, embedded and/or dynamic calls in PLs will get hairy if not turing complete and outright impossible to solve. Sorry, I don't follow. Got an example? Well, who's to say the following hypothetical plpgsql ex

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Sun, Oct 31, 2010 at 12:45 PM, Dimitri Fontaine wrote: > Bernd Helmle writes: >> This reminds me of a small discussion we had some years ago when i targeted >> this for the sake of completeness of ASS (see >> ). > > Discovered

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Heikki Linnakangas writes: >> In particular, embedded and/or dynamic calls in PLs will get hairy if >> not turing complete and outright impossible to solve. > > Sorry, I don't follow. Got an example? Well, who's to say the following hypothetical plpgsql example should be forgiven only in an excep

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On 31.10.2010 19:38, Dimitri Fontaine wrote: Sorry for the interruption, our program now continues... Dimitri Fontaine writes: That's exactly the road I want to avoid, because of the script parsing issues. In particular, embedded and/or dynamic calls in PLs will get hairy if not turing comp

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Sorry for the interruption, our program now continues... Dimitri Fontaine writes: > That's exactly the road I want to avoid, because of the script parsing issues. In particular, embedded and/or dynamic calls in PLs will get hairy if not turing complete and outright impossible to solve. -- Dim

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Heikki Linnakangas writes: > CREATE EXTENSION myextension ... SCHEMA myschema; > > And in the .sql file in the extension you could have special markers for the > schema, something like: That's exactly the road I want to avoid, because of the script parsing issues. Regards, -- Dimitri Fontaine h

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On 31.10.2010 14:46, Dimitri Fontaine wrote: What we could do is offer extension's author a way to find their operator or functions or whatever dynamically in SQL, so that writing robust pure-SQL functions is possible. What comes to mind now would be a way to call a function/operator/... by OID a

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Bernd Helmle writes: > This reminds me of a small discussion we had some years ago when i targeted > this for the sake of completeness of ASS (see > ). Discovered it, thanks for the pointer. > I didn't follow the previous discuss

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

--On 30. Oktober 2010 18:59:30 -0400 Tom Lane wrote: I'm not sure whether that really fixes anything, or just provides people with a larger-caliber foot-gun. See for example recent complaints about citext misbehaving if it's not in the public schema (or more generally, any schema not in the

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Hi, Thanks for your review! Tom Lane writes: > Dimitri Fontaine writes: >> ALTER EXTENSION ext SET SCHEMA name; >> ALTER EXTENSION ext SET SCHEMA foo TO bar; > >> I think that would end the open debate about search_path vs extension, >> because each user would be able to relocate his local

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Dimitri Fontaine writes: > As soon as we have that ability, we are able to provide for relocatable > extensions with the following command: > ALTER EXTENSION ext SET SCHEMA name; > ALTER EXTENSION ext SET SCHEMA foo TO bar; > I think that would end the open debate about search_path vs extens

[HACKERS] ALTER OBJECT any_name SET SCHEMA name

Hi, In the road to the extension patch, we already found some parts that have to be separated into their own patch. Here's another one. It occurred to me while implementing the pg_extension_objects() SRF that if we can list all objects that belong to an extension, certainly we also are able to mov