On Thursday 01 June 2006 21:38, Christopher Kings-Lynne wrote:
> > Marko's suggestion on producing a list of installed modules comes to
> > mind, and I suspect tools like pgadmin or ppa will want to be able to
> > show this information.
>
> My request for phpPgAdmin is to somehow be able to check i
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> I really think this is backwards: you should be looking for the .sql
>> files. Every module will have a .sql file, not every one will need a
>> .so file. See followup thread in -hackers where we're trying to hash
>> out design details.
> Not
For instance, I'd like to 'enable slony support' if the slony shared
library is present. PPA's slony support automatically executes the .sql
files, so all I need to know is if the .so is there.
I really think this is backwards: you should be looking for the .sql
files. Every module will have
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> My request for phpPgAdmin is to somehow be able to check if the .so file
> for a module is present.
> For instance, I'd like to 'enable slony support' if the slony shared
> library is present. PPA's slony support automatically executes the .
Marko's suggestion on producing a list of installed modules comes to mind, and
I suspect tools like pgadmin or ppa will want to be able to show this
information.
My request for phpPgAdmin is to somehow be able to check if the .so file
for a module is present.
For instance, I'd like to 'enabl
On Wednesday 31 May 2006 13:24, Martijn van Oosterhout wrote:
> On Wed, May 31, 2006 at 11:14:27AM -0400, Tom Lane wrote:
> > Is it worth adding a module name to the magic block, or should we just
> > leave well enough alone? It's certainly not something foreseen as part
> > of the purpose of that
On Wed, May 31, 2006 at 11:14:27AM -0400, Tom Lane wrote:
> ... The other
> stuff seems too blue-sky, and I'm not even sure that it's the right
> direction to proceed in. Marko seems to be envisioning a future where
> an extension module is this binary blob with install/deinstall/etc code
> all
On 5/31/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Marko Kreen" <[EMAIL PROTECTED]> writes:
>>> Could you serve this as special docstring instead? Eg:
>>> PG_MODULE(foomodule)
I have no objection to that, and see no real implementation problem with
it: we just add a "const char *" field to the ma
On Wed, May 31, 2006 at 11:14:27AM -0400, Tom Lane wrote:
> Is it worth adding a module name to the magic block, or should we just
> leave well enough alone? It's certainly not something foreseen as part
> of the purpose of that block. In the absence of some fairly concrete
> ideas what to do wit
"Marko Kreen" <[EMAIL PROTECTED]> writes:
>>> Could you serve this as special docstring instead? Eg:
>>> PG_MODULE(foomodule)
I have no objection to that, and see no real implementation problem with
it: we just add a "const char *" field to the magic block. The other
stuff seems too blue-sky, an
On 5/31/06, Martijn van Oosterhout wrote:
On Wed, May 31, 2006 at 01:08:41PM +0300, Marko Kreen wrote:
> On 5/8/06, Martijn van Oosterhout wrote:
> >All it requires is to include the header "pgmagic.h" and to put
> >somewhere in their source:
> >
> >PG_MODULE_MAGIC
>
> Could you serve this as s
On Wed, May 31, 2006 at 01:08:41PM +0300, Marko Kreen wrote:
> On 5/8/06, Martijn van Oosterhout wrote:
> >All it requires is to include the header "pgmagic.h" and to put
> >somewhere in their source:
> >
> >PG_MODULE_MAGIC
>
> Could you serve this as special docstring instead? Eg:
>
> PG_MODUL
On 5/8/06, Martijn van Oosterhout wrote:
This implements a proposal made last november:
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00578.php
All it requires is to include the header "pgmagic.h" and to put
somewhere in their source:
PG_MODULE_MAGIC
Could you serve this as spec
On Mon, May 08, 2006 at 10:32:47AM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > I was trying to find variables that when changed would make some things
> > corrupt. For example, a changed NAMEDATALEN will make any use of the
> > syscache a source of errors. A change in INDEX_MAX_KEY
Martijn van Oosterhout writes:
> On Sun, May 07, 2006 at 08:21:43PM -0400, Tom Lane wrote:
>> That seems way overkill to me. FUNC_MAX_ARGS is good to check, but
>> most of those other things are noncritical for typical add-on modules.
> I was trying to find variables that when changed would make
> > it's considered the linker's job to prevent loading 32-bit
> code into a
> > 64-bit executable or vice versa, so I don't think we need to be
> > checking for common assumptions about sizeof(long).
>
> I know ELF headers contain some of this info, and unix in
> general doesn't try to allow
On Sun, May 07, 2006 at 08:21:43PM -0400, Tom Lane wrote:
> > changes in any of the following:
>
> > PG_VERSION_NUM
> > CATALOG_VERSION_NO
> > the size of 8 basic C types
> > BLCKSZ=20
> > NAMEDATALEN=20
> > HAVE_INT64_TIMESTAMP
> > INDEX_MAX_KEYS
> > FUNC_MAX_ARGS
> > VARHDRSZ
> > MAXDIM
> > The
Martijn van Oosterhout writes:
> This implements a proposal made last november:
> http://archives.postgresql.org/pgsql-hackers/2005-11/msg00578.php
Ah, good, I'd been meaning to do this.
> changes in any of the following:
> PG_VERSION_NUM
> CATALOG_VERSION_NO
> the size of 8 basic C types
> BLC
This implements a proposal made last november:
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00578.php
Basically, it tries to catch people loading modules which belong to the
wrong version or have had certain constants changed, or architechture
mismatches. It's a bit more fine grained t
19 matches
Mail list logo
