* Tom Lane ([EMAIL PROTECTED]) wrote:
> It's essential IMHO that we provide pg_shadow and pg_group as reasonably
> backward-compatible views on the new pg_roles catalog. It's not at all
> negotiable that CREATE USER and CREATE GROUP have to still work in a
> sane fashion --- to say otherwise is to
Marc G. Fournier wrote:
> # ./configure `pg_config --configure`
> configure: error: invalid variable name: '--with-libraries
The intended mode of usage is
eval ./configure `pg_config --configure`
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of br
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> I've been making a bit of progress on adding a day field to the
> Interval struct (thanks to the help of this list and the find folks
> on IRC). Selects and basic math seem to be working, and the code is
> passing more regression tests than it
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> Yeah, you are right. I scratched elog/ereport(FATAL/PANIC), only found this
> one might be a suspect:
> In _hash_expandtable():
> if (!_hash_try_getlock(rel, start_nblkno, HASH_EXCLUSIVE))
> elog(PANIC, "could not get lock on supposedly new bucket
I've been making a bit of progress on adding a day field to the
Interval struct (thanks to the help of this list and the find folks
on IRC). Selects and basic math seem to be working, and the code is
passing more regression tests than it was before.
I'm running into a bit of a problem with
Marc G. Fournier wrote:
On Wed, 8 Jun 2005, Brett Schwarz wrote:
./configure `pg_config --configure | tr "'" " "`
Thought of that too, still blows up:
How about
./configure `pg_config --configure|sed s/\'//g`
Cheers
Mark
---(end of broadcast)-
On Wed, Jun 08, 2005 at 10:25:18PM -0400, Bruce Momjian wrote:
>
> I will post tomorrow on a plan for this.
If you need developer time, I'm available to work on this as it seems
higher priority to me that shared dependencies.
--
Alvaro Herrera ()
"Hay que recordar que la existencia en el cosmos
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
Yann,
> As we'd like to provide a postgresql database service to our students
> we'd like to create one database for each user. This user should be able
> to create new accounts for other users but only for his/her database.
That's on the TODO list. As far as I know, nobody is currently working
On Thu, Jun 09, 2005 at 12:26:06AM -0300, Marc G. Fournier wrote:
>
> pgsql74# ./configure `pg_config --configure | tr "'" " "`
> configure: WARNING: you should use --build, --host, --target
> configure: error: unrecognized option: -rpath=/usr/lib:/usr/local/lib
> Try `./configure --help' for more
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> This is not an issue except if the system might actually try to recover;
> which is not the case in the postmaster snippet you mention.
>
Yeah, you are right. I scratched elog/ereport(FATAL/PANIC), only found this
one might be a suspect:
In _hash_expand
On Wed, 8 Jun 2005, Brett Schwarz wrote:
I usually just look at config.log, and copy and
paste...but I am guessing you are trying to automate
this. Looks like pg_config adds '' around each option
when specifying --configure (i.e. '--with-libraries'),
at least on my system (Linux, PG803). You can
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> In other words, if FSM is wrong you will overwrite valid data? No
> thanks ... this is guaranteed to fail under simple concurrent usage,
> let alone any more interesting scenarios like FSM being actually out of
> date.
>
You are welcome ;-). The FSM race
I usually just look at config.log, and copy and
paste...but I am guessing you are trying to automate
this. Looks like pg_config adds '' around each option
when specifying --configure (i.e. '--with-libraries'),
at least on my system (Linux, PG803). You can try to
get rid of the ''. This seems to wor
One issue that comes to my mind is what to do when dealing with tables
that have assigned triggers and sequences (serials). Do we want to move
them as well or leave them in the source namespace?
They should all be moved. Remember nasties like indexes should be moved
as well as toast tables.
How are ppl using this? I'm trying to use it to re-configure, having
tried both tcsh and bash, and neither seem to 'work':
# ./configure `pg_config --configure`
configure: error: invalid variable name: '--with-libraries
So, is there another way I can use the output from pg_config to pass to
I will post tomorrow on a plan for this.
---
Matthew T. O'Connor wrote:
> Joshua D. Drake wrote:
>
> > Does it look like it is going to make it for 8.1?
>
>
> I certainly hope so. However, I don't have much time to put t
aAndreas Pflug wrote:
> Abhijit Menon-Sen wrote:
> > Are any PostgreSQL hackers planning to be at Linuxtag in Karlsruhe?
>
> I'll be at the booth.
Sorry, I will not be there this year. The past two years that I
attended were great and I encourage others to attend.
--
Bruce Momjian
Done.
---
Simon Riggs wrote:
> On Mon, 2005-06-06 at 22:09 -0400, Bruce Momjian wrote:
> > After months of being behind, I have gone through my entire mailbox and
> > addressed all the patches held over from 8.0beta. I have
On 08/06/2005 21:57:29, Bruce Momjian wrote:
> Andrew Dunstan wrote:
> > Atsushi Ogawa said:
> > >
> > > How about changing the function name of each usage?
> > >
> > > regexp_replace:replace first
> > > regexp_replace_all:replace all
> > > regexp_ic_replace: replace first and case
Andrew Dunstan wrote:
> Atsushi Ogawa said:
> >
> > How about changing the function name of each usage?
> >
> > regexp_replace:replace first
> > regexp_replace_all:replace all
> > regexp_ic_replace: replace first and case insensitive
> > regexp_ic_replace_all: replace all and case i
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
Atsushi Ogawa said:
>
> How about changing the function name of each usage?
>
> regexp_replace:replace first
> regexp_replace_all:replace all
> regexp_ic_replace: replace first and case insensitive
> regexp_ic_replace_all: replace all and case insensitive
>
That's just horrible. T
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
Joshua D. Drake wrote:
Does it look like it is going to make it for 8.1?
I certainly hope so. However, I don't have much time to put towards it
between now and July 1. Also, I will need significant help from someone
to get past some of the issues that I'm not really capable of. I am
try
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
Hi,
I was searching for some information about the storage of the user data
in postgresql. As far as I know there is one dictionary table for
storeing all the users of any known database, right?
As we'd like to provide a postgresql database service to our students
we'd like to create one database
Hello,
Does it look like it is going to make it for 8.1?
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandp
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
Bernd Helmle <[EMAIL PROTECTED]> writes:
> You can find a preliminary patch attached to this posting and i'm looking
> for comments, critics and perhaps some proposals for improvements /
> necessary changes i didn't consider yet.
The code seems fairly schizoid about whether the operation is an "
On Wed, Jun 08, 2005 at 08:25:12PM +0200, Bernd Helmle wrote:
> One issue that comes to my mind is what to do when dealing with tables that
> have assigned triggers and sequences (serials). Do we want to move them as
> well or leave them in the source namespace?
I'd think it's important that th
Robert Treat wrote:
> On Tuesday 07 June 2005 10:57, David Fetter wrote:
> > On Tue, Jun 07, 2005 at 10:27:28PM +0900, Atsushi Ogawa wrote:
> > > My idea is opposite. I think that the regexp_replace() should make
> > > "replace all" a default. Because the replace() of pgsql replaces all
> > > strin
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
I've took a look at the TODO item
Allow objects to be moved to different schemas
I've done some code so far which implements the syntax
ALTER [OBJECT] name SET SCHEMA name
where OBJECT currently is
SEQUENCE
TABLE
FUNCT
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
On Tuesday 07 June 2005 10:57, David Fetter wrote:
> On Tue, Jun 07, 2005 at 10:27:28PM +0900, Atsushi Ogawa wrote:
> > My idea is opposite. I think that the regexp_replace() should make
> > "replace all" a default. Because the replace() of pgsql replaces all
> > string, and regexp_replace() of ora
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
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> What I did include:
> make ReadPage(+empty_page) treat different of an empty page and non-empty
> one to avoid unnecesary read for new pages, that is:
In other words, if FSM is wrong you will overwrite valid data? No
thanks ... this is guaranteed to
On K, 2005-06-08 at 21:32 +0900, Atsushi Ogawa wrote:
>
> How about changing the function name of each usage?
>
> regexp_replace:replace first
> regexp_replace_all:replace all
> regexp_ic_replace: replace first and case insensitive
> regexp_ic_replace_all: replace all and cas
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The regression test file subselect.sql contains the following query under the
> heading "Correlated subselects":
> SELECT '' AS five, f1 AS "Correlated Field"
> FROM SUBSELECT_TBL
> WHERE (f1, f2) IN (SELECT f2, CAST(f3 AS int4) FROM SUBSELECT_TB
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
David Fetter wrote:
> On Tue, Jun 07, 2005 at 10:27:28PM +0900, Atsushi Ogawa wrote:
> > David Fetter wrote:
> > > Ogawa-san,
> > >
> > > I think that this would be a case for function overloading:
> > >
> > > function regexp_replace(
> > > string text, pattern text, replacement text
> > > ) R
The regression test file subselect.sql contains the following query under the
heading "Correlated subselects":
SELECT '' AS five, f1 AS "Correlated Field"
FROM SUBSELECT_TBL
WHERE (f1, f2) IN (SELECT f2, CAST(f3 AS int4) FROM SUBSELECT_TBL
WHERE f3 IS NOT NULL);
It has b
Abhijit Menon-Sen wrote:
Are any PostgreSQL hackers planning to be at Linuxtag in Karlsruhe?
I'll be at the booth.
Regards,
Andreas
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
"Mark Wong" <[EMAIL PROTECTED]> writes
>
> http://developer.osdl.org/markw/postgrescvs/
>
The last two jump points looks nice! They are pulled from CVS on 5.30 and
6.1. Where the performance improvements come from? I could remember:
* 5.30: avoid unnecessary foregin key check
Seems CRC patch is
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
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> I very seriously doubt that there would be *any* win
>
I did a quick proof-concept implemenation to test non-concurrent batch
insertion, here is the result:
Envrionment:
- Pg8.0.1
- NTFS / IDE
-- batch 16 pages extension --
test=# insert into t
On Wed, Jun 08, 2005 at 10:06:18AM +0530, Abhijit Menon-Sen wrote:
> Are any PostgreSQL hackers planning to be at Linuxtag in Karlsruhe?
Yes and there will be a PostgreSQL booth organized by Peter.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|O
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
66 matches
Mail list logo