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 woul
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 an
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, s
"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 fun
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 oth
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 di
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 thr
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
> > pgInstaller
> -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]
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
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
-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_d
-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 Fr
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 an
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 chang
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 adm
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.
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 ob
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 i
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_
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 admin
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 AndrewS
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
-
23 matches
Mail list logo
