Discussion tsearch in core patch, for inclusion shows
(http://archives.postgresql.org/pgsql-hackers/2007-01/msg01165.php and
following http://archives.postgresql.org/pgsql-hackers/2007-01/msg01186.php)
that there are some problems with contrib promotion and expansion.
I've encountered with bad
Nikolay Samokhvalov wrote:
1. Change default behaviour of MODULE_NAME.sql file so it will be
installed in MODULE_NAME schema instead of public (e.g., hstore
schema will contain all hstore relations and functions).
That might be a good idea in any case.
2. Allow running configure with
Nikolay Samokhvalov [EMAIL PROTECTED] writes:
1. Change default behaviour of MODULE_NAME.sql file so it will be
installed in MODULE_NAME schema instead of public (e.g., hstore
schema will contain all hstore relations and functions).
This might be a good idea, but it's hardly transparent; it
The problem with this proposal is that the ISPs aren't the ones running
configure --- these days, most people are running prebuilt packages
(RPMs or DEBs or what have you). So what you are hoping is that the
packagers will choose to do this and thereby force these modules into
the standard
Joshua D. Drake wrote:
The problem with this proposal is that the ISPs aren't the ones running
configure --- these days, most people are running prebuilt packages
(RPMs or DEBs or what have you). So what you are hoping is that the
packagers will choose to do this and thereby force these modules
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
I would like to see pgcrypto (or at least some of it's functionality) in
core.
I believe the reason we keep it separate is so that people can easily
make crypto-free versions of PG for use in countries where encryption
capability is considered
Well perhaps it is time to trim Contrib even further. E.g;
Why is ltree still in contrib? What prevents it from being in core?
not sure - ltree is quite useful but I'm not convinced it is really core
material
Why?
Why is pgcrypto,pgstattuple and pg_freespacemap in contrib?
I would
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
I would like to see pgcrypto (or at least some of it's functionality) in
core.
I believe the reason we keep it separate is so that people can easily
make crypto-free versions of PG for use in countries where encryption
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
I believe the reason we keep it separate is so that people can easily
make crypto-free versions of PG for use in countries where encryption
capability is considered subject to arms regulations. Not sure how
important that case really
You miss the point. Everybody knows that those laws are not too hard
to circumvent if you are willing to break the law. The question is
how hard is it for someone to distribute Postgres into one of those
countries *without* breaking any local law. We won't be making things
better if we
On Thu, 25 Jan 2007, Joshua D. Drake wrote:
The problem with this proposal is that the ISPs aren't the ones running
configure --- these days, most people are running prebuilt packages
(RPMs or DEBs or what have you). So what you are hoping is that the
packagers will choose to do this and
Oleg Bartunov wrote:
On Thu, 25 Jan 2007, Joshua D. Drake wrote:
The problem with this proposal is that the ISPs aren't the ones running
configure --- these days, most people are running prebuilt packages
(RPMs or DEBs or what have you). So what you are hoping is that the
packagers will
Joshua D. Drake wrote:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
I would like to see pgcrypto (or at least some of it's
functionality) in core.
I believe the reason we keep it separate is so that people can
easily make crypto-free versions of PG for use in
Joshua D. Drake [EMAIL PROTECTED] writes:
Oleg Bartunov wrote:
we have several requests to improve ltree, particularly, people want
to expand class of allowed symbols and configurable separator, which is
hard-coded right now. Also, we discussed GiN support for ltree.
O.k. but how does that
FWIW:
* Better packaging support, eg make it easier to add/remove an extension
module and control how pg_dump deals with it. We talked about that
awhile back but nobody did anything with the ideas.
+1
* Better documentation for the contrib modules; some of them are
reasonably well doc'd
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Oleg Bartunov wrote:
we have several requests to improve ltree, particularly, people want
to expand class of allowed symbols and configurable separator, which is
hard-coded right now. Also, we discussed GiN support for ltree.
O.k.
Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Oleg Bartunov wrote:
we have several requests to improve ltree, particularly, people want
to expand class of allowed symbols and configurable separator, which is
hard-coded right now. Also, we discussed GiN
Why is ltree still in contrib? What prevents it from being in core?
Nothing. But I don't see any advantage of placing it in core - it changes
nothing in SQL, API or feature. Moving tsearch2 into core allows to manage
configuration with nice SQL API, using SysCache, automatical rereading
I don't think two releases from API change to API change is enough -
postgresql is running larger and larger databases by now and I expect
people to upgrade less often in the future (and iirc you already said
something along the lines of recommending such things on occasion to
your customers
Teodor Sigaev wrote:
Why is ltree still in contrib? What prevents it from being in core?
Nothing. But I don't see any advantage of placing it in core - it
changes nothing in SQL, API or feature. Moving tsearch2 into core allows
to manage configuration with nice SQL API, using SysCache,
This might be a good idea, but it's hardly transparent; it can be
counted on to break the applications of just about everyone using those
modules today.
Hmm, can we make separate schema for all contib modules and include it in
default search_path? It will not touchs most users.
--
Teodor
Teodor Sigaev wrote:
This might be a good idea, but it's hardly transparent; it can be
counted on to break the applications of just about everyone using those
modules today.
Hmm, can we make separate schema for all contib modules and include it
in default search_path? It will not touchs
Joshua D. Drake wrote:
Teodor Sigaev wrote:
This might be a good idea, but it's hardly transparent; it can be
counted on to break the applications of just about everyone using those
modules today.
Hmm, can we make separate schema for all contib modules and include it
in default
23 matches
Mail list logo
