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
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
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 .sql
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:
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 in this
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 if the
On 5/8/06, Martijn van Oosterhout kleptog@svana.org 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
On Wed, May 31, 2006 at 01:08:41PM +0300, Marko Kreen wrote:
On 5/8/06, Martijn van Oosterhout kleptog@svana.org 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:
On 5/31/06, Martijn van Oosterhout kleptog@svana.org wrote:
On Wed, May 31, 2006 at 01:08:41PM +0300, Marko Kreen wrote:
On 5/8/06, Martijn van Oosterhout kleptog@svana.org wrote:
All it requires is to include the header pgmagic.h and to put
somewhere in their source:
PG_MODULE_MAGIC
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, and I'm not
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 with
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 magic block.
On Wed, May 31, 2006 at 11:14:27AM -0400, Tom Lane wrote:
snip
... 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 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 compiler used (only
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 different
Martijn van Oosterhout kleptog@svana.org 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
On Mon, May 08, 2006 at 10:32:47AM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org 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
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
Martijn van Oosterhout kleptog@svana.org 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
19 matches
Mail list logo
