Dear pgadmin friends,
A quick question. The makefile for the /contrib adminpacks doesn't
appear to use pgxs?
In the case of a package managed postgresql server install, using pgxs
is a really nice way of doing things for a variety of reasons.
Is there any thought to making the 8.1 adminpack use
> Andreas Pflug wrote:
>
> We're not talking about 10 times, but about exponentially rising times!
Even with a custom table implementation? I just tried a select * in the
query tool on a table with 87k rows in the query tool. It took 4 seconds
to run the query and 24 seconds to display it. I tried
Kris Jurka wrote:
Andreas Pflug wrote:
It's _always_ fine, because GetSchema obeys the search path and the
reengineered SQL is meant to be used in a search path situation as it
was at the time of reengineering. There are plenty of other
situations where the reduced form (omitting search-pathe
-u has been depreciated for psql, a proposed update the adminpack for
8.1 to reflect that.
- August
Index: admin81/README.admin81
===
--- admin81/README.admin81(revision 5009)
+++ admin81/README.admin81(working copy)
@@ -25,7
On 20/2/06 19:29, "Edward Di Geronimo Jr." <[EMAIL PROTECTED]>
wrote:
>> We need a rewrite of ctlSqlResult, but it must base on a virtual
>> wxListBox or wxListView, i.e. maintaining the data ourselves. On the
>> long run, extending ctlSqlBox to use it in View Data would be desirable.
>
> My c
> We need a rewrite of ctlSqlResult, but it must base on a virtual
> wxListBox or wxListView, i.e. maintaining the data ourselves. On the
> long run, extending ctlSqlBox to use it in View Data would be desirable.
My concern isn't speed but rather functionality. It doesn't really matter
to me if wx
Andreas Pflug wrote:
It's _always_ fine, because GetSchema obeys the search path and the
reengineered SQL is meant to be used in a search path situation as it
was at the time of reengineering. There are plenty of other situations
where the reduced form (omitting search-pathed schema) won't wor
Attached patch fixes pgagent commandline parsing so it rejects a
commandline with an invalid option, instead of silently ignoring it.
(Yes, I keep typing it wrong :))
win32 part only tested through the compiler, not actually run.
//Magnus
pgagent_commandline.patch
Description: pgagent_commandl
Hi!
When building pgadmin3 on Linux, pgagent ends up with a whole lot of
depdencies on X and friends - since it pulls in all of wxWidgets. I want
to deploy pgagent to a server, but I certainly don't have X on my
servers... Building it statically removes the dependency on the wx
libraries, but the
[EMAIL PROTECTED] wrote:
I've attached a preliminary patch to display the results of the Query Tool
using a grid control instead of a list.
Sorry to frustrate you, but using the grid is provenly even more
ineffective (on _all_ platforms) than the current one. wxGrid is known
to degrade drasti
Kris Jurka wrote:
Andreas Pflug wrote:
Kris Jurka wrote:
Actually it turns out that whether the schema gets in there or not
depends on the search path when the table is created.
That's what pgSchema::GetPrefix does too.
That's fine as long as you assume that the search path never ch
I've attached a preliminary patch to display the results of the Query Tool
using a grid control instead of a list. I've got one major problem with it
I'm a little stumped with though. The grid control doesn't seem to
consistantly maintain the focus, which makes it difficult to copy data
from it at
12 matches
Mail list logo
