On 6/13/2005 2:29 PM, Marc G. Fournier wrote:
On Mon, 13 Jun 2005, Andrew Dunstan wrote:
Marc G. Fournier wrote:
On Mon, 13 Jun 2005, Jan Wieck wrote:
On 6/12/2005 8:03 PM, Marc G. Fournier wrote:
Couldn't behaviour of REINDEX DATABASE not take that into account, and
'skip' the system
On Mon, 13 Jun 2005, Andrew Dunstan wrote:
Marc G. Fournier wrote:
On Mon, 13 Jun 2005, Jan Wieck wrote:
On 6/12/2005 8:03 PM, Marc G. Fournier wrote:
Couldn't behaviour of REINDEX DATABASE not take that into account, and
'skip' the system indices if not superuser?
Silently doing some
On Mon, 13 Jun 2005, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
On Mon, 13 Jun 2005, Jan Wieck wrote:
Silently doing something other than what the user requested ... I
don't think this is the right way to become the most popular open
source database in the world.
But, we
Marc G. Fournier wrote:
On Mon, 13 Jun 2005, Jan Wieck wrote:
On 6/12/2005 8:03 PM, Marc G. Fournier wrote:
Couldn't behaviour of REINDEX DATABASE not take that into account,
and 'skip' the system indices if not superuser?
Silently doing something other than what the user requested ...
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Mon, 13 Jun 2005, Jan Wieck wrote:
>> Silently doing something other than what the user requested ... I
>> don't think this is the right way to become the most popular open
>> source database in the world.
> But, we are already doing that, no? :)
On Mon, 13 Jun 2005, Jan Wieck wrote:
On 6/12/2005 8:03 PM, Marc G. Fournier wrote:
Couldn't behaviour of REINDEX DATABASE not take that into account, and
'skip' the system indices if not superuser?
Silently doing something other than what the user requested ... I don't think
this is the ri
Am Montag, den 13.06.2005, 08:16 -0400 schrieb Jan Wieck:
> On 6/12/2005 8:03 PM, Marc G. Fournier wrote:
>
> > Couldn't behaviour of REINDEX DATABASE not take that into account, and
> > 'skip' the system indices if not superuser?
>
> Silently doing something other than what the user requested .
On 6/12/2005 8:03 PM, Marc G. Fournier wrote:
Couldn't behaviour of REINDEX DATABASE not take that into account, and
'skip' the system indices if not superuser?
Silently doing something other than what the user requested ... I don't
think this is the right way to become the most popular open
On Mon, 13 Jun 2005, Greg Stark wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Why all the choices? What cases are there for doing one without the
other? If you want to get 'fine tuned', do a 'REINDEX TABLE' ... I can
see REINDEX SYSTEM and REINDEX DATABASE (includes SYSTEM), but not
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >> Why all the choices? What cases are there for doing one without the
> >> other? If you want to get 'fine tuned', do a 'REINDEX TABLE' ... I can
> >> see REINDEX SYSTEM and REINDEX DATABASE (includes SYSTEM), but not the
> >> USER one ..
> >
> >
On Sun, 12 Jun 2005, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
On Sat, 11 Jun 2005, Tom Lane wrote:
It's always bothered me too. How about
REINDEX SYSTEM -> system tables (current meaning of R. DATABASE)
REINDEX USER -> all non-system tables
REINDEX DATABASE -> both of t
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Sat, 11 Jun 2005, Tom Lane wrote:
>> It's always bothered me too. How about
>>
>> REINDEX SYSTEM -> system tables (current meaning of R. DATABASE)
>> REINDEX USER -> all non-system tables
>> REINDEX DATABASE -> both of the above
> Why all the c
On Sat, 11 Jun 2005, Tom Lane wrote:
Bruce Momjian writes:
Kaare Rasmussen wrote:
I consider this a bug, or at least a badly thought out name. I can't
understand that someone approved 'reindex database' to mean 'reindex the
system tables of a database'.
Agreed.
It's always bothered me to
Tom Lane wrote:
> Bruce Momjian writes:
> > Kaare Rasmussen wrote:
> >> I consider this a bug, or at least a badly thought out name. I can't
> >> understand that someone approved 'reindex database' to mean 'reindex the
> >> system tables of a database'.
>
> > Agreed.
>
> It's always bothered m
Bruce Momjian writes:
> Kaare Rasmussen wrote:
>> I consider this a bug, or at least a badly thought out name. I can't
>> understand that someone approved 'reindex database' to mean 'reindex the
>> system tables of a database'.
> Agreed.
It's always bothered me too. How about
REINDEX
On 6/10/2005 3:04 PM, Tom Lane wrote:
pgbench: I see repeated complaints on -performance about how
pgbench results are misleading. Why are we shipping it with
PostgreSQL then?
It's handy to have *some* simple concurrent-behavior test included,
even if it's not something we put a lot of stoc
Kaare Rasmussen wrote:
>
> > Either you're misunderstanding what "reindex database" does (it reindexes
> > only the system catalogs), or you're misunderstanding what reindexdb does
>
> OK, I was taking the face value here.
>
> I consider this a bug, or at least a badly thought out name. I can't
> Either you're misunderstanding what "reindex database" does (it reindexes
> only the system catalogs), or you're misunderstanding what reindexdb does
OK, I was taking the face value here.
I consider this a bug, or at least a badly thought out name. I can't
understand that someone approved 're
On 2005-06-10, Kaare Rasmussen <[EMAIL PROTECTED]> wrote:
>> But not as easy as:
>> psql -c "reindex database {database}" {database}
>
> Well it was just to show that there really is no need for a program just for
> this functionality.
Either you're misunderstanding what "reindex database" does (
> But not as easy as:
> psql -c "reindex database {database}" {database}
Well it was just to show that there really is no need for a program just for
this functionality.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unr
Josh Berkus writes:
> I had a lot of time to kill on airplanes recently so I've gone
> digging through /contrib in an effort to sort out what's in
> there and try to apply some consistent rules to it.
Sorry for not responding sooner; I'm catching up on back email.
As already noted, I agree with
On Friday 10 June 2005 10:54 am, Kaare Rasmussen wrote:
> > actually I think part of the point of this was to give a command
> > line version of the reindex command, like we have for vaccum. If
> > that still matters, then it should probably stay. Actually it
> > should probably be converted to C
> actually I think part of the point of this was to give a command line
> version of the reindex command, like we have for vaccum. If that still
> matters, then it should probably stay. Actually it should probably be
> converted to C and moved to /src/bin.
>
Wouldn't something like
echo 'REINDE
On Thu, 9 Jun 2005, Josh Berkus wrote:
Marc,
What did I post? *raised eyebrow*
Didn't you grep the source for "GPL"? Or was it someone else?
Someone else :)
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrap
Josh Berkus writes:
> Didn't you grep the source for "GPL"? Or was it someone else?
That was me...
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
Marc,
> What did I post? *raised eyebrow*
Didn't you grep the source for "GPL"? Or was it someone else?
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 6: Have you searched our list archives?
On Wed, 8 Jun 2005, Josh Berkus wrote:
Neil,
I've volunteered to do this in the past, and the response was that it is
something that only members of core are in a position to do this. That
is perfectly reasonable, but that was quite some time ago -- it would be
nice to see some movement on thi
Neil,
> I've volunteered to do this in the past, and the response was that it is
> something that only members of core are in a position to do this. That
> is perfectly reasonable, but that was quite some time ago -- it would be
> nice to see some movement on this...
I thought I *was* moving on t
Tom Lane wrote:
That's been the intention for a very long time: everything in the core
tarball should be under the same license. Someone's got to do the
legwork of contacting the module authors involved to see if they're
willing to relicense ... and so far it just hasn't gotten to the top
of the
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Wed, 8 Jun 2005, Matthew D. Fuller wrote:
>> That's why you COPY the files in the repo, cvs rm the old locations
>> (so they still exist on older tags/branches), and do some surgery on
>> the new locations to remove the old tags (though you can't
On Wed, 8 Jun 2005, Matthew D. Fuller wrote:
On Wed, Jun 08, 2005 at 06:50:06PM -0300 I heard the voice of
Marc G. Fournier, and lo! it spake thus:
On Wed, 8 Jun 2005, Alvaro Herrera wrote:
On Wed, Jun 08, 2005 at 04:21:46PM -0300, Marc G. Fournier wrote:
Why would it destroy the history? I
On Wed, Jun 08, 2005 at 05:54:08PM -0500, Matthew D. Fuller wrote:
> That's why you COPY the files in the repo, cvs rm the old locations
> (so they still exist on older tags/branches), and do some surgery on
Hmm, while we are at the subject of playing with our CVS server, could
we fix some other
On Wed, Jun 08, 2005 at 06:50:06PM -0300 I heard the voice of
Marc G. Fournier, and lo! it spake thus:
> On Wed, 8 Jun 2005, Alvaro Herrera wrote:
> >On Wed, Jun 08, 2005 at 04:21:46PM -0300, Marc G. Fournier wrote:
> >>
> >>Why would it destroy the history? Its easy enough to move the files to a
On Tue, 07 Jun 2005 14:53:32 -0300, Josh Berkus wrote:
[Discussion snipped]
> xml and xml2: both by John Gray ([EMAIL PROTECTED]). John, why do we have
> two of these? Otherwise, data_types/.
contrib/xml2 is a lot better than /xml. When I submitted the new code,
Bruce felt that /xml should be k
On Wed, 8 Jun 2005, Alvaro Herrera wrote:
On Wed, Jun 08, 2005 at 04:21:46PM -0300, Marc G. Fournier wrote:
On Wed, 8 Jun 2005, Peter Eisentraut wrote:
Am Dienstag, 7. Juni 2005 19:53 schrieb Josh Berkus:
I think it would also be helpful to users if we could create
subdirectories to organize
On Wed, Jun 08, 2005 at 04:21:46PM -0300, Marc G. Fournier wrote:
> On Wed, 8 Jun 2005, Peter Eisentraut wrote:
>
> >Am Dienstag, 7. Juni 2005 19:53 schrieb Josh Berkus:
> >>I think it would also be helpful to users if we could create
> >>subdirectories to organize contrib into categories. This w
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Wed, 8 Jun 2005, Peter Eisentraut wrote:
>> I think this is out of the question both because these categories are fuzzy
>> and it would destroy the CVS history.
> Why would it destroy the history? Its easy enough to move the files to a
> subdir
On Wed, 8 Jun 2005, Peter Eisentraut wrote:
Am Dienstag, 7. Juni 2005 19:53 schrieb Josh Berkus:
I think it would also be helpful to users if we could create
subdirectories to organize contrib into categories. This would
help users and packagers find what they want. These
directories would be
On Wed, 8 Jun 2005, Josh Berkus wrote:
Peter,
Packagers should simply build all contrib items. No extra options are
needed.
No, they shoudn't. 3 of the packages currently in /contrib are GPL.
Building them makes all of PostgreSQL GPL.
Then they should be removed ...
Marc G. Fourni
On Wed, Jun 08, 2005 at 11:13:01AM -0700, Josh Berkus wrote:
> People:
>
> > > No, it means the distributors are illegally distributing software they
> > > don't have permission to distribute. The GPL doesn't make everything
> > > else GPL right away, that's a myth.
>
> I'm not talking out of my
Josh Berkus writes:
> I will point out that all three "GPL" modules are currently unmaintained.
> I don't know that anyone has seen Massimo in years. Simply dropping them
> seems the easiest answer.
The original authors of the backend code haven't been seen on this list
in a long time, eithe
People:
> > No, it means the distributors are illegally distributing software they
> > don't have permission to distribute. The GPL doesn't make everything
> > else GPL right away, that's a myth.
I'm not talking out of my hat here. I consulted a staff member of the FSF
about it (will give nam
On Wednesday 08 June 2005 12:05, Alvaro Herrera wrote:
> On Wed, Jun 08, 2005 at 08:45:42AM -0700, Josh Berkus wrote:
> > Peter,
> >
> > > Packagers should simply build all contrib items. No extra options are
> > > needed.
> >
> > No, they shoudn't. 3 of the packages currently in /contrib are GP
On Wed, Jun 08, 2005 at 08:59:37AM -0700, Josh Berkus wrote:
> Peter,
>
> > I think this is out of the question both because these categories are fuzzy
> > and it would destroy the CVS history. It might be equally effective to
> > organize the README file along these lines.
>
> Ach, I forgot abo
Josh Berkus writes:
> Tom,
>> The fix for that is to remove or relicense those packages, not to
>> complicate the build process.
> OK. Then we'll make BSD licensing an absolute requirement for /contrib?
That's been the intention for a very long time: everything in the core
tarball should be und
On Wed, Jun 08, 2005 at 08:45:42AM -0700, Josh Berkus wrote:
> Peter,
>
> > Packagers should simply build all contrib items. No extra options are
> > needed.
>
> No, they shoudn't. 3 of the packages currently in /contrib are GPL.
> Building them makes all of PostgreSQL GPL.
No, it means the
Tom,
> The fix for that is to remove or relicense those packages, not to
> complicate the build process.
OK. Then we'll make BSD licensing an absolute requirement for /contrib?
Also, we'll add --build-all-contrib to ./configure?
--
Josh Berkus
Aglio Database Solutions
San Francisco
-
Josh Berkus writes:
>> Packagers should simply build all contrib items. No extra options are
>> needed.
> No, they shoudn't. 3 of the packages currently in /contrib are GPL.
> Building them makes all of PostgreSQL GPL.
The fix for that is to remove or relicense those packages, not to
compli
Peter,
> I think this is out of the question both because these categories are fuzzy
> and it would destroy the CVS history. It might be equally effective to
> organize the README file along these lines.
Ach, I forgot about this lovely property of CVS. Well, scratch that proposal.
SVN is lo
Peter,
> Packagers should simply build all contrib items. No extra options are
> needed.
No, they shoudn't. 3 of the packages currently in /contrib are GPL.
Building them makes all of PostgreSQL GPL.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of
On Tue, Jun 07, 2005 at 02:53:32PM -0300, Josh Berkus wrote:
>
> noupdate: this is a cool example of a simple C trigger and would
> be lovely to have in a doc somewhere. However, its
> functionality is easily replicated through a simple PL/pgSQL
> trigger so it seems unnecessary as a contrib modul
Hi Robert,
> > reindexdb: now obsolete per the REINDEX {database} command.
> > Remove from contrib.
>
> actually I think part of the point of this was to give a command line
> version of the reindex command, like we have for vaccum. If that
> still
> matters, then it should probably stay. Actua
Am Dienstag, 7. Juni 2005 19:53 schrieb Josh Berkus:
> I think it would also be helpful to users if we could create
> subdirectories to organize contrib into categories. This would
> help users and packagers find what they want. These
> directories would be:
> data_types/
> functions/
> utilities
elein wrote:
intarray: data_types/
what does this do that arrays do not?
It provides lossy indexes that work well on big arrays;
as well as some quite useful convenience functions that
work on arrays of ints.
---(end of broadcast)---
TIP 7: do
Josh Berkus wrote:
intagg: what does this module do which is not already available
through the built-in array functions and operators? Maybe I
don't understand what it does. Unnatributed in the README. Move
to pgfoundry?
Short summary:
Is there an equivalent of "int_array_enum()" built in
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>>
>>>lo: another special data type. Is its functionality required
>>>anymore? It appears to be a workaround to some limitations of
>>>our large object interface which may no longer exist.
>
> I **think** the lo datatype is for ODBC binary access.
Andrew,
> userlocks is just a very thin interface to functionality that's really in
> the backend. What's left in contrib/userlock probably isn't even
> copyrightable in any case. The best bet is probably to re-implement it in
> the backend directly.
>
> Removing it certainly isn't a good idea; th
> adddepend: is this still needed, or would a proper
> dump-and-reload from 7.2 add the dependancy information anyway?
No, a 7.2 to 7.3 or later upgrade will not have full dependency
information using pg_dump.
That said, I would abandon the module anyway. I don't recall testing it
for a 7.2 to 8.
lo: another special data type. Is its functionality required
anymore? It appears to be a workaround to some limitations of
our large object interface which may no longer exist.
I **think** the lo datatype is for ODBC binary access.
Sincerely,
Joshua D. Drake
--
Your PostgreSQL solutio
On Tue, Jun 07, 2005 at 02:53:32PM -0300, Josh Berkus wrote:
> Moving to PgFoundry is NOT "Demotion"
>
Yeah, I agree. Lots of people understand "search in pgfoundry.org" much
easily than "see contrib/adddepend". (I agree with most of the rest of
your com
On 2005-06-07, Josh Berkus wrote:
> userlocks: another GPL script, with the problems that entails.
> Also problematic as it relies heavily on per-record OIDs,
> something we tell users not to do. Overall, should be removed.
> Author: Massimo.
userlocks is just a very thin interface to function
On Tue, 2005-06-07 at 13:53, Josh Berkus wrote:
> mysql: these utilities have been moved to project sites (such as
> GBorg), and I believe that my2pg is broken with current versions
> of MySQL. Can we remove this from contrib?
>
I believe this version now lives at
http://gborg.postgresql.org/pro
a few comments scattered inline...
On Tue, Jun 07, 2005 at 02:53:32PM -0300, Josh Berkus wrote:
> Folks,
>
> I had a lot of time to kill on airplanes recently so I've gone
> digging through /contrib in an effort to sort out what's in
> there and try to apply some consistent rules to it. Before
>
Folks,
I had a lot of time to kill on airplanes recently so I've gone
digging through /contrib in an effort to sort out what's in
there and try to apply some consistent rules to it. Before
people read further, please understand that this is just an
initial discussion on what will and won't be in
64 matches
Mail list logo
