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
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 ..
The main argument
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 the
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
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 ... I
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
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? :) I know
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 ...
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
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
On Sat, 11 Jun 2005, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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.
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 choices? What
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 the
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
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
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
Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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 'REINDEX
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 and
Josh Berkus josh@agliodbs.com 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
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
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 (it reindexes
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
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?
Josh Berkus josh@agliodbs.com 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
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!:
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?
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:
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/
I
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 module.
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
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
Josh Berkus josh@agliodbs.com 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,
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
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
Josh Berkus josh@agliodbs.com 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
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 about this
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 GPL.
Building
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 name as
Josh Berkus josh@agliodbs.com 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
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 hat here.
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.
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
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
subdirectory
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 would
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
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
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 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, 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?
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 remove
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
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
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
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
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
On 2005-06-07, Josh Berkus josh@agliodbs.com 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
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 comments
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
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.0
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; the
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.
Yes, ISTR
63 matches
Mail list logo
