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 search
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 to
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 Siga
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, aut
> 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 custo
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
diction
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,
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 l
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 do
"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
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 fo
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
>>> p
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 ther
> 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 w
"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
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
>> 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 contri
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
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
> 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 "stan
"Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes:
> 1. Change default behaviour of .sql file so it will be
> installed in 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 can be
count
Nikolay Samokhvalov wrote:
> 1. Change default behaviour of .sql file so it will be
> installed in 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 "--with-" (or
> "-
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
23 matches
Mail list logo
