I'm not sure what you mean by PR in this context, what has that got to
do with this?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgadmin-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
ine.
My interest is in having a PostgreSQL user have access to the
PostgreSQL website and announce list. That can be put on the
PostgreSQL installer or pgadmin (when included with the PostgreSQL
distribution at least). I don't mind which, but it needs to be in at
least one of those pl
if you don't it skips
that menu option. I have zero interest in putting options on the menus
of pgadmin when used with other products, only in making sure people
that use open source PostgreSQL get access to the open source
PostgreSQL web site. Call it context-sensitive menus. That would
On Sun, 2009-04-26 at 20:03 +0100, Dave Page wrote:
> On Sun, Apr 26, 2009 at 7:31 PM, Simon Riggs wrote:
> >
> > On Sun, 2009-04-26 at 17:45 +0100, Dave Page wrote:
> >
> >> > Alphabetic seems best, whatever kind of type they are.
> >>
> >>
likely to be messy.
How about an extra radio button for Array/Non-Array? That removes the
confusion.
The appearance of alpha sort stops people from looking further down the
list for other items.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent v
a Move rather than a Copy action.
Some additional ideas from me: We could drag/drop objects onto
tablespaces to move them, or onto users to grant them access for users.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgadmin-hacke
be great to have.
Alphabetic seems best, whatever kind of type they are.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgadmin-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
to work!?!
* Want to be able to specify ConnectionLimit for users via dialog
* If there are >20 (N?) objects, then show that using a breakdown. e.g.
A-C, D-G, H-M, N-S, T-V, W-Z. So when we have 100s of objects we can
still retain sanity.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Tr
hem. So you need to specify which two servers
you're interested in comparing and how to identify them externally.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgadmin-hackers mailing list ([email protected])
To make changes to
On Mon, 2008-10-27 at 11:42 -0400, Robert Treat wrote:
> On Monday 20 October 2008 05:25:29 Simon Riggs wrote:
> > I'm looking to implement the following functions for Hot Standby, to
> > allow those with administrative tools or management applications to have
> > mo
we won't keep
> >> track of this record by record).
> >>
>
> No interest from pgAdmin's pov.
I would ask: why not? Why is PITR not part of pgAdmin's capability?
> >> * pg_reload_conf() will not force re-read of recovery.conf since that
> >> may require extra work and doesn't seem that important, if we have the
> >> manual override mentioned above.
> >>
> >> All desirable? All possible? Any others?
> >
>
> Hope this helps.
Yes, thanks.
> Oh, I almost forgot. I see you mailed a few projects (pgAdmin, pgpool,
> pgbouncer). Perhaps you should ask phpPgAdmin's guys too?
Not on that list, if you are could you pass it on.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgadmin-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
?
On Mon, 2008-10-20 at 10:25 +0100, Simon Riggs wrote:
> I'm looking to implement the following functions for Hot Standby, to
> allow those with administrative tools or management applications to have
> more control during re
On Mon, 2008-10-20 at 10:25 +0100, Simon Riggs wrote:
> What else do we need?
> * pg_freeze_recovery()
> * pg_unfreeze_recovery()
Two more functions
pg_freeze_recovery_cleanup()
pg_unfreeze_recovery_cleanup()
These would allow recovery to continue normally, except for ro
ed() returns bigint (txid) seems better.
I am more than happy to add an id version as well, if anybody sees the
need for that. Just say.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgadmin-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
On Mon, 2008-10-20 at 18:45 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2008-10-20 at 17:44 -0300, Alvaro Herrera wrote:
> >> That's been "extended with an epoch counter" per the docs; I don't think
> >> that
On Mon, 2008-10-20 at 17:44 -0300, Alvaro Herrera wrote:
> Simon Riggs escribió:
> >
> > On Mon, 2008-10-20 at 16:22 -0400, Robert Haas wrote:
> > > > * pg_last_recovered_xact_xid()
> > > > Will throw an ERROR if *not* executed i
mode.
> > returns bigint
>
> Should these return xid?
Perhaps, but they match txid_current() which returns bigint.
http://developer.postgresql.org/pgdocs/postgres/functions-info.html
Thanks for checking.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services an
ned above.
All desirable? All possible? Any others?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgadmin-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
me-config-connection.html#RUNTIME-CONFIG-CONNECTION-SETTINGS
They're user settable, so pgadmin could offer that as an option. But you
can augment the pgadmin userid with a SET command to implement this
yourself as a user, see ALTER USER.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.
a multi-statement query either now.
Sounds like we need the ability to run multiple commands one after the
other before we do that. Shame we lost the multi-stmt query, but it was
correct to do that.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
--
On Fri, 2007-10-05 at 21:24 +0100, Dave Page wrote:
> Simon Riggs wrote:
> > It would be even better if there was an option to do that CONCURRENTLY,
> > i.e. add the new index and then drop the old one afterwards. (It's
> > unfortunate that there isn't a REINDE
On Fri, 2007-10-05 at 13:55 +0100, Dave Page wrote:
> Guillaume Lelarge wrote:
> > Simon Riggs a écrit :
> >> It would be great if there was a database-level option so that any new
> >> indexes would default to using CONCURRENTLY.
> >>
> >> This would
nd then drop the old one afterwards. (It's
unfortunate that there isn't a REINDEX concurrently, but there isn't
yet).
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)---
TIP 1: if posting/reading through
f use concurrent builds?
Got a crash on Beta5 yesterday while creating indexes, not been able to
reproduce it. Sorry.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)---
TIP 3: Have you checked our extensiv
24 matches
Mail list logo
