question about single project containing multiple extensions

[Bear Giles]

I noticed that the META.json file allows a package to provide multiple extensions. That raises several questions:

1. Are they compiled to a single .so?

2. Can we specify dependencies among extensions?

The extensions I checked in yesterday would fall into this pattern if they shared code. Both 'bignum' and 'cert' would be provided (easy) but there needs to be a dependency between them since the latter type uses the former.

Thanks,

Bear

[David E. Wheeler]

On Jul 20, 2015, at 8:33 AM, Bear Giles <bgi...@coyotesong.com> wrote:

> I noticed that the META.json file allows a package to provide multiple extensions. That raises several questions:
>
> 1. Are they compiled to a single .so?

PGXN is not responsible for compilation; the PostgreSQL build system is. But I suspect the answer to your question is “no”. In general, each extension is its own thing. But you can fiddle with it in your Makefile.

> 2. Can we specify dependencies among extensions?

Yes, that’s what the prereqs section is for.

http://pgxn.org/spec/#prereqs

Best,

David

[Bear Giles]

Sorry, I wasn't clear. What I'm saying is that I want to have

"provides": {
  "pgtap": {
    "file": "sql/pgtap.sql",
    "docfile": "doc/pgtap.mmd",
    "version": "0.2.4",
    "abstract": "Unit testing assertions for PostgreSQL"
  },
  "schematap": {
    "file": "sql/schematap.sql",
    "docfile": "doc/schematap.mmd",
    "version": "0.2.4",
    "abstract": "Schema testing assertions for PostgreSQL"
  }
}

​but specify that schematap depends on pgtap.

Or is this an all-or-nothing affair - if you load one you have to load everything? 

​Bear​

--
You received this message because you are subscribed to the Google Groups "PGXN Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pgxn-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David E. Wheeler]

On Jul 20, 2015, at 9:22 AM, Bear Giles <bgi...@coyotesong.com> wrote:

> ​but specify that schematap depends on pgtap.

I see. There’s nothing like that in the META.json becauase they are both there in that one distribution.

> Or is this an all-or-nothing affair - if you load one you have to load everything?

You should declare such dependencies in your .control files. See the “requires” directive here:

http://www.postgresql.org/docs/current/static/extend-extensions.html

Best,

David

[Jim Nasby]

That said; dependency handling is a known weakness of pgxnclient, and
possibly META.json. It seems reasonable to have 2 extensions in one PGXN
package that have a dependency, but until pgxn client understands deps I
don't know that there's much point.

The other issue is lack of reasonable dependency handling by Postgres
itself. There's been a recent thread on hackers about that:
http://www.postgresql.org/message-id/557E0520...@2ndquadrant.com
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com

[David E. Wheeler]

On Jul 20, 2015, at 1:40 PM, Jim Nasby <Jim....@BlueTreble.com> wrote:

>> You should declare such dependencies in your .control files. See the “requires” directive here:
>>
>> http://www.postgresql.org/docs/current/static/extend-extensions.html
>
> That said; dependency handling is a known weakness of pgxnclient, and possibly META.json. It seems reasonable to have 2 extensions in one PGXN package that have a dependency, but until pgxn client understands deps I don't know that there's much point.

Er, I don’t know what the META.json could do here. When you download a distribution, you should build the whole thing. If there are multiple extensions with mutual dependencies, the Makefile should set up the appropriate build order dependencies, the .control files should declare them, and the test suite should load them all. I could see it might be useful to have metadata about mutual dependencies in the META.json, but don’t see how that’d have any affect on building, testing, or installation, none of which PGXN has anything to do with.

> The other issue is lack of reasonable dependency handling by Postgres itself. There's been a recent thread on hackers about that: http://www.postgresql.org/message-id/557E0520...@2ndquadrant.com

Yeah, hoping that improves.

Best,

David