4 ms·
Hi nice idea! I'm mostly a DB guy and I also face this kind of challenges because I'll soon need to share my pg codebase over different servers. Until now I wa
by MarHoff 10y ago
Hi nice idea! I'm mostly a DB guy and I also face this kind of challenges because I'll soon need to share my pg codebase over different servers.
Until now I was more investigating the native extension mechanism of PostgreSQL: https://www.postgresql.org/docs/current/static/extend-extensions.html https://www.postgresql.org/docs/current/static/extend-extens.... But I totally get that a more ad-hoc and versatile solution can be more fitted.
Don't be to rude because it's really minimalist, I actually just published this afternoon my first tiny test on GitHub here : https://github.com/MarHoff/Test https://github.com/MarHoff/Test
So i definitively had to say Hi there ;)
- oelmekki 10y agoThanks! Love the idea of packaging stuff in extensions. Actually, both ideas cool work well together: pgrebase to do the dev work with live reload, then packaging to distribute FOOS libs for postgres. Maybe it's time for pg third party libs to take off :)
- oskari 10y agoPackaging your functions in an extension has the advantage that it allows you to call remote functions when using the postgres_fdw Foreign Data Wrapper. PostgreSQL 9.6 added extension function pushdown as a new feature allowing functions to be executed on the remote side as long as the extension is registered with the foreign server. This avoids having to fetch all the data from the remote side to execute a function locally, see https://www.postgresql.org/docs/current/static/postgres-fdw.html#AEN181695 https://www.postgresql.org/docs/current/static/postgres-fdw....
- thejosh 10y agoDownside is that every developer who works locally has to have the up to date extensions, or if you use docker-compose or something and have the extensions in your repo/sub-repo you could include itn that way.