Re: [HACKERS] adminpack and pg_catalog
Robert Treat wrote: While I don't disagree that this is an important feature, the fact that it is being designed with pgadmin specific backwards compatability (for example the functions that rename core functions) leaves me dubious as to it being a more general solution. Because of that I would be comfortable with acting on #3. The rename happened because when one of the functions was moved into core, someone decided to rename it along the way which broke compatibility with previous versions of pgAdmin. Whilst I won't in any way deny that the adminpack was specifically written for pgAdmin though, I have no problem with it being enhanced to provide non-core functionality for other admin tools in the future... in fact I would encourage it. I think it's better to support as many admin tools as possible from one contrib module, rather than for each tool to have it's own. Regards Dave. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] adminpack and pg_catalog
On Monday 06 November 2006 13:12, Simon Riggs wrote:
> On Mon, 2006-11-06 at 09:02 +, Dave Page wrote:
> > Neil Conway wrote:
> > > On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote:
> > >> Nothing except initdb should add objects in pg_catalog. AFAICS,
> > >> adminpack doesn't have any special requirements, so it should behave
> > >> like all other contrib modules.
> > >
> > > Where are we on this? When this topic was last discussed, the three
> > > alternatives were:
> > >
> > > (1) Modify contrib/adminpack to not use the pg_catalog schema,
> > > per the consensus that contrib/ packages installing objects
> > > into that schema is broken behavior
> > >
> > > (2) Don't modify contrib/adminpack, for the sake of backward
> > > compatibility
> > >
> > > (3) Remove contrib/adminpack from the Postgres distribution
> > >
> > > I think the discussion was edging toward #3, but #2 is the only option
> > > that I'm not happy with. Any other opinions out there?
> >
> > Looking back over the thread, it appears that only you and Peter
> > objected to it as it is now. Tom, Andreas and myself were of the opinion
> > it was fine as it is, and whilst he didn't comment on how it should be
> > implemented, Simon made the point that supporting admin tools from the
> > core distribution was important which I take to mean he is against #3.
>
> Definitely against #3. [Argument: not just pgAdmin, essential feature]
>
While I don't disagree that this is an important feature, the fact that it is
being designed with pgadmin specific backwards compatability (for example the
functions that rename core functions) leaves me dubious as to it being a more
general solution. Because of that I would be comfortable with acting on #3.
Now, if I ignore the above, and focus on that I would like to see this
functionality because it helps me with phppgadmin, then I would lean toward
#1 (for a number of reasons really)
Personally I think I'd rather see the whole thing pulled, renamed to its own
schema, and toss in a version function and a kill backend function and let it
go on its merry way... in any case #2 just seems to be the worst of all
possibilities.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] adminpack and pg_catalog
On Mon, 2006-11-06 at 13:37 -0500, Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > At the moment we only allow 2 types of table. Approved core catalog > > tables and user tables. > > > ISTM we need 3 types of tables, with the additional type being add-on > > system functionality, such as adminpack, > > What? The adminpack module only creates functions. AFAIK the namespace is the issue, not the type of object. As I mentioned, we can add LWlock extensions but we don't have an official home for other database objects. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] adminpack and pg_catalog
"Simon Riggs" <[EMAIL PROTECTED]> writes: > At the moment we only allow 2 types of table. Approved core catalog > tables and user tables. > ISTM we need 3 types of tables, with the additional type being add-on > system functionality, such as adminpack, What? The adminpack module only creates functions. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] adminpack and pg_catalog
On Mon, 2006-11-06 at 09:02 +, Dave Page wrote: > Neil Conway wrote: > > On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote: > >> Nothing except initdb should add objects in pg_catalog. AFAICS, > >> adminpack doesn't have any special requirements, so it should behave > >> like all other contrib modules. > > > > Where are we on this? When this topic was last discussed, the three > > alternatives were: > > > > (1) Modify contrib/adminpack to not use the pg_catalog schema, > > per the consensus that contrib/ packages installing objects > > into that schema is broken behavior > > > > (2) Don't modify contrib/adminpack, for the sake of backward > > compatibility > > > > (3) Remove contrib/adminpack from the Postgres distribution > > > > I think the discussion was edging toward #3, but #2 is the only option > > that I'm not happy with. Any other opinions out there? > > Looking back over the thread, it appears that only you and Peter > objected to it as it is now. Tom, Andreas and myself were of the opinion > it was fine as it is, and whilst he didn't comment on how it should be > implemented, Simon made the point that supporting admin tools from the > core distribution was important which I take to mean he is against #3. Definitely against #3. [Argument: not just pgAdmin, essential feature] At the moment we only allow 2 types of table. Approved core catalog tables and user tables. ISTM we need 3 types of tables, with the additional type being add-on system functionality, such as adminpack, but also possibly including performance logging tables, extended trace tools, security packages (e.g. Veil) etc etc. We have made provision for user add-ons to allocate LWlocks and shared memory, but no provision for additional tables. Surely we must be able to accommodate things as simple as additional tables? So we would then have (change names as appropriate) - core catalog - catalog extensions - user tables. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] adminpack and pg_catalog
Neil Conway wrote: On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote: Nothing except initdb should add objects in pg_catalog. AFAICS, adminpack doesn't have any special requirements, so it should behave like all other contrib modules. Where are we on this? When this topic was last discussed, the three alternatives were: > (1) Modify contrib/adminpack to not use the pg_catalog schema, per the consensus that contrib/ packages installing objects into that schema is broken behavior (2) Don't modify contrib/adminpack, for the sake of backward compatibility (3) Remove contrib/adminpack from the Postgres distribution I think the discussion was edging toward #3, but #2 is the only option that I'm not happy with. Any other opinions out there? Looking back over the thread, it appears that only you and Peter objected to it as it is now. Tom, Andreas and myself were of the opinion it was fine as it is, and whilst he didn't comment on how it should be implemented, Simon made the point that supporting admin tools from the core distribution was important which I take to mean he is against #3. Regards, Dave. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] adminpack and pg_catalog
On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote: > Nothing except initdb should add objects in pg_catalog. AFAICS, > adminpack doesn't have any special requirements, so it should behave > like all other contrib modules. Where are we on this? When this topic was last discussed, the three alternatives were: (1) Modify contrib/adminpack to not use the pg_catalog schema, per the consensus that contrib/ packages installing objects into that schema is broken behavior (2) Don't modify contrib/adminpack, for the sake of backward compatibility (3) Remove contrib/adminpack from the Postgres distribution I think the discussion was edging toward #3, but #2 is the only option that I'm not happy with. Any other opinions out there? Cheers, Neil ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] adminpack and pg_catalog
On Sat, 2006-10-21 at 12:37 +0200, Peter Eisentraut wrote: > Dave Page wrote: > > If you change it you will make it useless as pgAdmin won't > > necessarily find the functions it expects. You might as well just > > remove it (which will almost certainly cause delays to pgAdmin - and > > pgInstallers - release as I'll need to find time to put it all back > > how it was). > > If pgAdmin is going to dictate what we do with adminpack, adminpack > should rather be shipped with pgAdmin. Admin tools are critical. adminpack is being made available for any and all admin packages, so all tools, including for example psql *could* be enhanced to use those. Whether they do is up to them, but at least their life is potentially easier. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
FW: [pgadmin-hackers] FW: [HACKERS] adminpack and pg_catalog
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dave Page > Sent: 21 October 2006 21:20 > To: PgAdmin Hackers > Subject: [pgadmin-hackers] FW: [HACKERS] adminpack and pg_catalog > > > [Ooops, forgot to CC the list] And then got the wrong one. D'oh!! > -- Forwarded Message > From: Dave Page > Date: Sat, 21 Oct 2006 21:18:42 +0100 > To: Peter Eisentraut <[EMAIL PROTECTED]> > Conversation: [HACKERS] adminpack and pg_catalog > Subject: Re: [HACKERS] adminpack and pg_catalog > > > > > On 21/10/06 12:13, "Peter Eisentraut" <[EMAIL PROTECTED]> wrote: > > > Dave Page wrote: > >> Well as adminpack is specifcally and primarily written to support > >> pgAdmin, deliberately breaking it for current and older releases of > >> pgAdmin does seem like a *really* dopey thing to do. So > yeah, I would > >> prefer it was removed than broken, even if to the annoyance of the > >> packagers and users that bugged us to get it included in the first > >> place. > > > > I understand that randomly breaking it is not the way to go. > > > > But how it this going to continue? A new pgAdmin release might > > conceivably want to add or change the adminpack. > > I think that's unlikely, but yes, it's possible. > > > Will that have to > > wait for a new server release. > > PgAdmin is released on virtually the same timetable as > PostgreSQL - it has > to be to sync up the docs and levels of support in the > Windows pgInstaller > distro, so that's not an issue. > > > Given the understanding that adminpack > > is specifically for pgAdmin support, I don't see any advantage in > > shipping it with the server, the buggers notwithstanding. > > The message we've consistently had from both packagers of > PostgreSQL and > users is that the module should be included in /contrib and > not pgAdmin, > precisely because it is a server side module, and many people don't > necessarily want to install pgAdmin, or bits of it separately on their > servers. We here the same argument about pgAgent from time to > time, but that > isn't really a candidate for inclusion in /contrib due to it's current > reliance on wxWidgets - otherwise I'd be arguing to get that > included as > well. > > Regards, Dave > > -- End of Forwarded Message > > > ---(end of > broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org > ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] adminpack and pg_catalog
On Friday 20 October 2006 21:03, Neil Conway wrote:
> On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote:
> > Nothing except initdb should add objects in pg_catalog. AFAICS,
> > adminpack doesn't have any special requirements, so it should behave
> > like all other contrib modules.
>
> Okay. Are there any opinions on whether we should make this change to
> contrib/adminpack now (i.e. during the 8.2 beta), later (for 8.3), or
> not all at?
>
Not saying we should or shouldn't, but if we are going to do it, istm we ought
to do it now while we are still in beta. Is there a backwards compatability
issue for older systems? (Not that this doesn't get worse if we release yet
another release with it)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] adminpack and pg_catalog
Dave Page wrote: > If you change it you will make it useless as pgAdmin won't > necessarily find the functions it expects. You might as well just > remove it (which will almost certainly cause delays to pgAdmin - and > pgInstallers - release as I'll need to find time to put it all back > how it was). If pgAdmin is going to dictate what we do with adminpack, adminpack should rather be shipped with pgAdmin. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] adminpack and pg_catalog
-Original Message- From: "Neil Conway" <[EMAIL PROTECTED]> To: "Dave Page" Cc: "PostgreSQL-development" Sent: 20/10/06 21:19 Subject: Re: adminpack and pg_catalog > It breaks in the sense of "completely not working" :) No, it does not 'break pg_dump'. What you have shown is that pg_dump doesn't dump adminpack which is exactly what we want, and perfectly correct behaviour from pg_dump. Regards, Dave ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] adminpack and pg_catalog
-Original Message- From: "Neil Conway" <[EMAIL PROTECTED]> To: "Peter Eisentraut" <[EMAIL PROTECTED]> Cc: "pgsql-hackers@postgresql.org" ; "Dave Page" Sent: 21/10/06 02:03 Subject: Re: [HACKERS] adminpack and pg_catalog On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote: > Nothing except initdb should add objects in pg_catalog. AFAICS, > adminpack doesn't have any special requirements, so it should behave > like all other contrib modules. > Okay. Are there any opinions on whether we should make this change to > contrib/adminpack now (i.e. during the 8.2 beta), later (for 8.3), or not all at? If you change it you will make it useless as pgAdmin won't necessarily find the functions it expects. You might as well just remove it (which will almost certainly cause delays to pgAdmin - and pgInstallers - release as I'll need to find time to put it all back how it was). Regards, Dave ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] adminpack and pg_catalog
Neil Conway <[EMAIL PROTECTED]> writes: > On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote: >> Nothing except initdb should add objects in pg_catalog. AFAICS, >> adminpack doesn't have any special requirements, so it should behave >> like all other contrib modules. > Okay. Are there any opinions on whether we should make this change to > contrib/adminpack now (i.e. during the 8.2 beta), later (for 8.3), or > not all at? AFAIR the point of adminpack was to support pgAdmin, which expects those functions to be in pg_catalog. At some point we might as well just take it out instead of whack it until it meets some arbitrary restrictions and isn't at all backwards-compatible anymore. (No, I don't find these arguments that it mustn't put anything in pg_catalog to be very compelling ... if we seriously believed that, we'd have arranged for the system to enforce it.) regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] adminpack and pg_catalog
On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote: > Nothing except initdb should add objects in pg_catalog. AFAICS, > adminpack doesn't have any special requirements, so it should behave > like all other contrib modules. Okay. Are there any opinions on whether we should make this change to contrib/adminpack now (i.e. during the 8.2 beta), later (for 8.3), or not all at? -Neil ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] adminpack and pg_catalog
Neil Conway wrote: > On Fri, 2006-10-20 at 05:52 +0100, Dave Page wrote: > >> The adminpack was originally written and intended to become builtin >> functions >> > > This is not unique to adminpack: several contrib modules might > eventually become (or have already become) builtins, but adminpack is > the only module that defines objects in the pg_catalog schema. > .. which appears simply pragmatic, taken that it features server maintenance functions, not functions usually called from user applications. > >> pg_catalog was used to ensure compatibility in the future >> > > This is again not unique to adminpack. If users install a contrib module > into a schema that is in their search path, then if the module is > subsequently moved to pg_catalog, no queries will need to be changed. If > users install a module into some schema that isn't in their search path > and use explicit schema references, they are essentially asking for > their application to break if the object moves to a different schema. > Please note that adminpack is intended for administrator's use, and should be robust to (i.e. not dependent on) search path. We previously had this dependency in pgadmin, and found it sucks. Putting the stuff in pg_catalog works as desired and has no negative effects (apart from the contrib not working after pg_dump/pg_restore if not installed, which is expected behaviour anyway). However, adminpack was crippled to the edge of usability for me already, I'm prepared to see it fade away further (Since there's still no pg_terminate_backend available which is definitely needed, I regularly need to install my personal adminpack). Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] adminpack and pg_catalog
Neil Conway wrote: > Why does adminpack install functions into pg_catalog? This is > inconsistent with the rest of the contrib/ packages, not to mention > the definition of pg_catalog itself (which ought to hold builtin > object definitions). Nothing except initdb should add objects in pg_catalog. AFAICS, adminpack doesn't have any special requirements, so it should behave like all other contrib modules. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] adminpack and pg_catalog
On Fri, 2006-10-20 at 05:52 +0100, Dave Page wrote: > The adminpack was originally written and intended to become builtin > functions This is not unique to adminpack: several contrib modules might eventually become (or have already become) builtins, but adminpack is the only module that defines objects in the pg_catalog schema. > pg_catalog was used to ensure compatibility in the future This is again not unique to adminpack. If users install a contrib module into a schema that is in their search path, then if the module is subsequently moved to pg_catalog, no queries will need to be changed. If users install a module into some schema that isn't in their search path and use explicit schema references, they are essentially asking for their application to break if the object moves to a different schema. > > And as AndrewSN pointed out on IRC, it also breaks pg_dump. > > It does? In what way? It breaks in the sense of "completely not working" :) % pg_dump | grep file_write % cd contrib/adminpack % grep -A1 file_write adminpack.sql CREATE FUNCTION pg_catalog.pg_file_write(text, text, bool) RETURNS bigint AS '$libdir/adminpack', 'pg_file_write' LANGUAGE C VOLATILE STRICT; % psql -f adminpack.sql CREATE FUNCTION CREATE FUNCTION CREATE FUNCTION CREATE FUNCTION CREATE FUNCTION CREATE FUNCTION CREATE FUNCTION CREATE FUNCTION % pg_dump | grep file_write % -Neil ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] adminpack and pg_catalog
On Fri, 2006-10-20 at 11:50 +0200, Andreas Pflug wrote: > Having pg_dump not saving the function definitions is an intended > behaviour. The manual defines the pg_catalog schema as containing "the system tables and all the built-in data types, functions, and operators" (section 5.7.5). adminpack is none of the above, so I don't think it should be located in pg_catalog. > I'd consider installing contrib modules as an act of installation, not > something that backup/restore should perform AFAICS this is inconsistent with how every other contrib module behaves: installing the contrib module into a database results in DDL for that contrib module being included in pg_dump's output. > (finally, pg_restore isn't able to do so, since it can't provide > the dll/lib module). This is not related to adminpack per se: pg_dump is never be able to provide the shared object for any C language UDF. By your logic, pg_dump shouldn't emit DDL for any such function. -Neil ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] adminpack and pg_catalog
Neil Conway wrote: > Why does adminpack install functions into pg_catalog? This is > inconsistent with the rest of the contrib/ packages, not to mention the > definition of pg_catalog itself (which ought to hold builtin object > definitions). And as AndrewSN pointed out on IRC, it also breaks > pg_dump. > Having pg_dump not saving the function definitions is an intended behaviour. Actually, this was different with admin80, and restoring a 8.0 backup to a 8.1 server will throw several errors now. I'd consider installing contrib modules as an act of installation, not something that backup/restore should perform (finally, pg_restore isn't able to do so, since it can't provide the dll/lib module). Regards, Andreas ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] adminpack and pg_catalog
On 19/10/06 19:37, "Neil Conway" <[EMAIL PROTECTED]> wrote: > Why does adminpack install functions into pg_catalog? This is > inconsistent with the rest of the contrib/ packages, not to mention the > definition of pg_catalog itself (which ought to hold builtin object > definitions). The adminpack was originally written and intended to become builtin functions, and in fact most of it has. pg_catalog was used to ensure compatibility in the future, and because it's the only schema we can be sure we'll find in any given database. > And as AndrewSN pointed out on IRC, it also breaks > pg_dump. It does? In what way? I don't recall ever having any trouble restoring dumps in the past. Regards, Dave. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] adminpack and pg_catalog
On Thu, Oct 19, 2006 at 02:37:34PM -0400, Neil Conway wrote: > Why does adminpack install functions into pg_catalog? This is > inconsistent with the rest of the contrib/ packages, not to mention the > definition of pg_catalog itself (which ought to hold builtin object > definitions). And as AndrewSN pointed out on IRC, it also breaks > pg_dump. When we wrote newsysviews we faced the same dilema of where to put things. We ultimately decided on a pg_ schema in the hope that no one else would use that name (we also prefaced everything in the schema with pg_, but a big reason for that was potential inclusion into core). -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] adminpack and pg_catalog
Why does adminpack install functions into pg_catalog? This is inconsistent with the rest of the contrib/ packages, not to mention the definition of pg_catalog itself (which ought to hold builtin object definitions). And as AndrewSN pointed out on IRC, it also breaks pg_dump. -Neil ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
