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
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
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
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 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
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
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: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
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.
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
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
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
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, 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
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, 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
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
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
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
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
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
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
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 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 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
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
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
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
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 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
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 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
> 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
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!
--
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
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
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
> 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
> 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
> 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
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
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
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
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 :-)
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
> -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:
...
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: 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 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.
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 :)
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 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 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 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 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
> -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
> 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,
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
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
59 matches
Mail list logo
