On Tue, 2006-01-31 at 03:50 -0400, Marc G. Fournier wrote:
> On Tue, 31 Jan 2006, Tino Wildenhain wrote:
>
> > Devrim GUNDUZ schrieb:
> >> Hi,
> >>
> > ...
> >>> Are you going to work with the underlying system's package manager, or
> >>> put everything in /usr/local?
> >>
> >>
> >> We'll work
Tino Wildenhain wrote:
Jonah H. Harris schrieb:
I had to deal with an installer written in python and several in
Java... IMHO, Java would be a better language for this and you could
build off some nice OSS installers that already exist (such as
IzPack). Just my 2 cents :)
Yes! Use Java for
> 3) For every privilege descriptor in CPD whose action is
> INSERT, UPDATE,
>or REFERENCES without a column name, privilege descriptors are also
>created and added to CPD for each column C in O for which
> A holds the
>corresponding privilege with grant option. For each such column,
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tino
> Wildenhain
> Sent: 31 January 2006 07:55
> To: Rick Gigger
> Cc: Marc G. Fournier; Joshua D. Drake; Christopher Browne;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] New project la
Hi,
On Mon, 2006-01-30 at 20:41 -0800, Jeffrey W. Baker wrote:
> How will you do an orderly upgrade from one revision to the next,
> including all the dependencies?
We are still in planning phase, any ideas of how to do that is welcome.
> How will you distribute security updates?
We are still
Hi,
On Mon, 2006-01-30 at 19:35 -0800, Christopher Browne wrote:
> > We are actively looking for developers for the project. Please drop me
> > an e-mail if you want to join this project. We will use Python, so you
> > need to be a Python guy to join the project. We are in planning phase,
> > if y
Hi,
On Tue, 2006-01-31 at 09:15 +, Dave Page wrote:
> > As was said, a gui to produce postgresql.conf files (off host)
> > can be of value.
>
> pgAdmin?
Installer should "produce" a postgresql.conf, based on some selections
via the interface. Then we will use pgAdmin to edit, improve, etc.
> -Original Message-
> From: Devrim GUNDUZ [mailto:[EMAIL PROTECTED]
> Sent: 31 January 2006 09:25
> To: Dave Page
> Cc: Tino Wildenhain; Rick Gigger; Marc G. Fournier; Joshua D.
> Drake; Christopher Browne; pgsql-hackers@postgresql.org; Burcu GUZEL
> Subject: Re: [HACKERS] New project
Hi,
On Tue, 2006-01-31 at 08:34 +0100, Tino Wildenhain wrote:
> > http://pgfoundry.org/projects/pgnixinstaller/
> >
> > We are actively looking for developers for the project. Please drop me
> > an e-mail if you want to join this project. We will use Python, so you
> > need to be a Python guy
Hi,
On Tue, 2006-01-31 at 08:36 +0100, Tino Wildenhain wrote:
> >>Are you going to work with the underlying system's package manager, or
> >>put everything in /usr/local?
> >
> >
> > We'll work with the package manager -- I'm an RPM guy ;)
> >
> RPM isnt the only packaging system out there ;)
Hi,
On Mon, 2006-01-30 at 22:45 -0500, Vivek Khera wrote:
> > However none of them are PostgreSQL Installers, none of them has the
> > ability to customize the packages and none of them has the ability to
> > install the community packages, etc. :)
>
> You need to take a sniff over at the FreeBS
Hi,
On Mon, 2006-01-30 at 21:27 -0500, Jonah H. Harris wrote:
> I had to deal with an installer written in python and several in
> Java... IMHO, Java would be a better language for this and you could
> build off some nice OSS installers that already exist (such as
> IzPack). Just my 2 cents :)
Dave Page schrieb:
...
As was said, a gui to produce postgresql.conf files (off host)
can be of value.
pgAdmin?
Well, strictly spoken a gui text editor is a gui... but I rather
had in mind something guided with buttons, select boxes and stuff
and references to documentation, calculations
> -Original Message-
> From: Tino Wildenhain [mailto:[EMAIL PROTECTED]
> Sent: 31 January 2006 10:53
> To: Dave Page
> Cc: Rick Gigger; Marc G. Fournier; Joshua D. Drake;
> Christopher Browne; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] New project launched : PostgreSQL GUI
Dave Page schrieb:
...
Well, strictly spoken a gui text editor is a gui... but I rather
had in mind something guided with buttons, select boxes and stuff
and references to documentation, calculations and the like.
:-)
Err, yes. pgAdmin? It's somewhat more than a simple text editor.
Ah, ri
Tino Wildenhain wrote:
Figuring out the correct values for some of the buffers and costs
is still a bit tough. Otoh, I guess there is no easy way to predict
all these.
pgAdmin has a mechanism to suggest values (currently for autovacuum and
listen_address only), which waits for expansion :-)
Devrim GUNDUZ wrote:
Hi,
On Mon, 2006-01-30 at 21:27 -0500, Jonah H. Harris wrote:
I had to deal with an installer written in python and several in
Java... IMHO, Java would be a better language for this and you could
build off some nice OSS installers that already exist (such as
IzPack). Just
Some time ago, the tab completion code for the SET command was changed to read
the list of available settings from the pg_settings table. This means that
by the time you're done completing SET TRANSACTION ISOLATION, you've already
sent a query and the command will be disallowed. It's not a maj
Marc G. Fournier wrote:
I'm one of the 'foundry admin team', and I can definitely state that we
have been accepting projects as ppl are proposing them ... as to
gborg->pgfoundry, the only thing that has been holding that up is that
the two systems are not compatible at the DB end of things, so
> Hi,
>
> On Mon, 2006-01-30 at 19:35 -0800, Christopher Browne wrote:
>> > We are actively looking for developers for the project. Please
>> > drop me an e-mail if you want to join this project. We will use
>> > Python, so you need to be a Python guy to join the project. We
>> > are in planning ph
> Hi,
>
> On Mon, 2006-01-30 at 22:45 -0500, Vivek Khera wrote:
>> > However none of them are PostgreSQL Installers, none of them has the
>> > ability to customize the packages and none of them has the ability to
>> > install the community packages, etc. :)
>>
>> You need to take a sniff over at
> Devrim GUNDUZ wrote:
>> Hi,
>> On Mon, 2006-01-30 at 21:27 -0500, Jonah H. Harris wrote:
>>> I had to deal with an installer written in python and several in
>>> Java... IMHO, Java would be a better language for this and you could
>>> build off some nice OSS installers that already exist (such as
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Some time ago, the tab completion code for the SET command was changed
> to read the list of available settings from the pg_settings table.
> This means that by the time you're done completing SET TRANSACTION
> ISOLATION, you've already sent a query an
Is there any chance for psql opening a new session if it's inside a
transaction and use that to do whatever querying is needed ? Just
something like the control connection on ftp (analogy not very good).
That could cause other surprises though (could fail for example due to
too many connections ope
Devrim GUNDUZ wrote:
Hi,
On Mon, 2006-01-30 at 19:35 -0800, Christopher Browne wrote:
We are actively looking for developers for the project. Please drop me
an e-mail if you want to join this project. We will use Python, so you
need to be a Python guy to join the project. We are in planning pha
J. Andrew Rogers wrote:
A graphical installer for Unix is fine, but please, do not make it
anything like Oracle's graphical installer. Oracle's graphical install
process gives command line installs a good name for ease of use.
J. Andrew Rogers
I heartily second that!
--
> On Mon, Jan 30, 2006 at 04:35:15PM -0500, Mark Woodward wrote:
>> It gets so frustrating sometimes, it isn't so black and white, there are
>> many levels of gray. The PostgreSQL project is trying so hard to be
>> neutral, that it is making itself irrelevant.
>>
>> Designing and including features
> On Mon, 30 Jan 2006, Mark Woodward wrote:
>
>> It gets so frustrating sometimes, it isn't so black and white, there are
>> many levels of gray. The PostgreSQL project is trying so hard to be
>> neutral, that it is making itself irrelevant.
>
> We are making ourselves irrelevant because we encoura
Mark Woodward wrote:
I don't understand what you mean by PostgreSQL trying to be neutral.
Postgres focuses on what it's good at, being a database. It's not
really for or against anything. The PostgreSQL team is not interested
in maintaining code that so clearly falls outside of the scope.
Tha
On Jan 31, 2006, at 12:54 AM, Tino Wildenhain wrote:
Rick Gigger schrieb:
I don't see why anyone has a problem with this. I am certainly
never going to use it but if it helps someone who isn't a linux
person to use it on a project when they would have used something
else (like mysql) o
Hi,
Currently, i'm helping out in a project testing the cache miss rates
for different buffer replacement policies. I've tried asking the
postgresql channel on IRC but was directed to this mailing list instead.
At the moment, i've replaced freelist.c with an implementation of the
LRU policy and t
On Mon, Jan 30, 2006 at 05:10:03PM -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Joachim Wieland wrote:
> >> I wonder if there is a policy on when schema-qualified names should
> >> be used in ereport/elog messages.
> > If it's not too hard to do, I would add the schema
Joachim Wieland <[EMAIL PROTECTED]> writes:
> Making assumptions on the length of an error message seems to be moot
> anyway, since you don't know the length of the names of user defined objects
> in advance, nor do you know the length of the translated message strings in
> different languages.
It
Christopher Browne wrote:
Devrim GUNDUZ wrote:
Hi,
On Mon, 2006-01-30 at 21:27 -0500, Jonah H. Harris wrote:
I had to deal with an installer written in python and several in
Java... IMHO, Java would be a better language for this and you could
build off some nice OSS installers that already exis
On Mon, Jan 30, 2006 at 08:53:54PM -0800, Joshua D. Drake wrote:
> >If I could install Oracle on Debian/AMD64 with a shell script, I'd drop
> >Postgresql in a heartbeat.
> >
> >Obviously anybody is welcome and able to just write whatever software
> >they feel is needed, but go ahead and count me am
On Tue, Jan 31, 2006 at 11:46:03AM +, Andreas Pflug wrote:
> Tino Wildenhain wrote:
>
> >
> >Figuring out the correct values for some of the buffers and costs
> >is still a bit tough. Otoh, I guess there is no easy way to predict
> >all these.
>
> pgAdmin has a mechanism to suggest values (cu
On Tue, Jan 31, 2006 at 03:41:06PM +0100, Csaba Nagy wrote:
> Is there any chance for psql opening a new session if it's inside a
> transaction and use that to do whatever querying is needed ? Just
> something like the control connection on ftp (analogy not very good).
> That could cause other surp
On Tue, Jan 31, 2006 at 01:46:42PM -0500, Tom Lane wrote:
> The direction that we ought to be going in is to add separate fields to
> error reports that contain just the names of the relevant objects (without
> any other decoration). This is needed anyway to allow client-side
> programs to extract
Jeffery,
> > PostgreSQL *desperately* needs a better means of dealing with
> > configuration (though I guess I shouldn't be pushing too hard for this
> > since the current state of affairs brings me business). Any
> > improvement in this area would be very welcome.
> > http://pgfoundry.org/project
Michael Paesold wrote:
> Perhaps not multiple connections, but multiple transactions per connection,
> like Oracle supports, AFAIK. All with a big ;-) of course. I doubt it would
> be easy to implement that. The assumption
> one-connection-has-one-transaction is probably pretty deeply burried i
On Tue, 2006-01-31 at 12:11 -0800, Josh Berkus wrote:
> Jeffery,
>
> > > PostgreSQL *desperately* needs a better means of dealing with
> > > configuration (though I guess I shouldn't be pushing too hard for this
> > > since the current state of affairs brings me business). Any
> > > improvement in
Jeffrey,
> I agree that some instrumentation of the backend might be needed. But
> several of the performance-critical parameters seem tractable:
>
> Effective cache size - should be easy to monitor the system for this
> Shared buffers - easy to start from a rule-of-thumb and monitor usage
> Work
Tom Lane <[EMAIL PROTECTED]> writes:
> Hm, that's a bit nasty.
>
> The only plan I can think of involves reading the list of available
> variable names in advance and keeping it around. However, I'm not
> sure I want psql issuing such a query at connection startup whether
> or not the info will
On Tue, Jan 31, 2006 at 12:36:31PM -0800, Jeffrey W. Baker wrote:
> Random page cost - should possible to determine this at runtime
Before worrying about random_page_cost at all it makes a lot more sense
to look at the query cost estimates, some of which are pretty far out of
wack.
--
Jim C. Nasb
On Tue, 2006-01-31 at 17:06 -0600, Jim C. Nasby wrote:
> On Tue, Jan 31, 2006 at 12:36:31PM -0800, Jeffrey W. Baker wrote:
> > Random page cost - should possible to determine this at runtime
>
> Before worrying about random_page_cost at all it makes a lot more sense
> to look at the query cost est
On Tue, 2006-01-31 at 13:02 -0600, Jim C. Nasby wrote:
> On Tue, Jan 31, 2006 at 11:46:03AM +, Andreas Pflug wrote:
> > Tino Wildenhain wrote:
> >
> > >
> > >Figuring out the correct values for some of the buffers and costs
> > >is still a bit tough. Otoh, I guess there is no easy way to predi
Csaba Nagy wrote:
Is there any chance for psql opening a new session if it's inside a
transaction and use that to do whatever querying is needed ? Just
something like the control connection on ftp (analogy not very good).
That could cause other surprises though (could fail for example due to
too
On Tue, Jan 31, 2006 at 03:11:50PM -0800, Jeffrey W. Baker wrote:
> On Tue, 2006-01-31 at 17:06 -0600, Jim C. Nasby wrote:
> > On Tue, Jan 31, 2006 at 12:36:31PM -0800, Jeffrey W. Baker wrote:
> > > Random page cost - should possible to determine this at runtime
> >
> > Before worrying about rando
Added to TODO:
o Prevent tab completion of SET TRANSACTION from querying the
database and therefore preventing the transaction isolation
level from being set.
Currently, SET causes a database lookup to check all
supported session variables. This
It could read all the SET variables in at startup?
Peter Eisentraut wrote:
Some time ago, the tab completion code for the SET command was changed to read
the list of available settings from the pg_settings table. This means that
by the time you're done completing SET TRANSACTION ISOLATION, you
Christopher Kings-Lynne wrote:
> It could read all the SET variables in at startup?
Right, but do we want to do that even if they never ask for a tab
completion? I think the easiest might be to just save the list on first
tab call.
On Tue, 2006-01-31 at 20:18 -0500, Bruce Momjian wrote:
> Christopher Kings-Lynne wrote:
> > It could read all the SET variables in at startup?
>
> Right, but do we want to do that even if they never ask for a tab
> completion? I think the easiest might be to just save the list on first
> tab cal
Rod Taylor wrote:
> On Tue, 2006-01-31 at 20:18 -0500, Bruce Momjian wrote:
> > Christopher Kings-Lynne wrote:
> > > It could read all the SET variables in at startup?
> >
> > Right, but do we want to do that even if they never ask for a tab
> > completion? I think the easiest might be to just sa
On Tue, 2006-01-31 at 20:32 -0500, Rod Taylor wrote:
> Perhaps a second database connection could be established during
> situations when running tab completion and other psql commands is
> impossible on the main one?
That would lead to inconsistencies, because of differences between the
two sessi
On Tue, 2006-01-31 at 20:53 -0500, Bruce Momjian wrote:
> Rod Taylor wrote:
> > On Tue, 2006-01-31 at 20:18 -0500, Bruce Momjian wrote:
> > > Christopher Kings-Lynne wrote:
> > > > It could read all the SET variables in at startup?
> > >
> > > Right, but do we want to do that even if they never as
I believe psql keeps the password in memory.
\c seems to be able to change databases without asking for the password
again.
What if that role has a maximum of one connection, etc.?
Chris
---(end of broadcast)---
TIP 5: don't forget to increase
On Wed, 2006-02-01 at 10:28 +0800, Christopher Kings-Lynne wrote:
> > I believe psql keeps the password in memory.
> >
> > \c seems to be able to change databases without asking for the password
> > again.
>
> What if that role has a maximum of one connection, etc.?
Considering it would only be
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Wed, 2006-02-01 at 10:28 +0800, Christopher Kings-Lynne wrote:
>> What if that role has a maximum of one connection, etc.?
> Considering it would only be used when the alternative was to say
> "Sorry, tab completion unavailable", I really don't see these
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Some time ago, the tab completion code for the SET command was changed
> to read the list of available settings from the pg_settings table.
> This means that by the time you're done completing SET TRANSACTION
> ISOLATION, you've already sent a query an
59 matches
Mail list logo
