On Fri, 2007-08-03 at 18:16 -0400, Tom Lane wrote:
In any case this is getting pretty darn far away from a one-liner patch.
I think it needs more thought and more testing than we can spare now.
Agreed.
We're much further behind with this release than ever before, so we need
to put the cut
Rohit Khare wrote:
PostgreSQL has the oldest community of coders, and PostgreSQL itself is
the oldest product. Still its performance (in some areas) and GUI does
not match MySQL. MySQL .NET Driver gives very good performance for the
MySQL Database, FireBird .NET Driver gives performance for
Seeing the history of PostgreSQL development, following features are
expected in pgAdmin:
(1) Facility to insert a column in between other columns during table
design.
(2) Facility to view relationship diagram.
(3) Facility to view table performance level graphically.
(4) More documented
I once discussed with you all regarding Oracle's FlashBack Query feature to
recover a database to a certain point of time. That time you all suggested
some indepth cons of this and how it is resource hungry.
One more feature that I am not sure PostgreSQL has is, row-level,
column-level security.
Rohit Khare wrote:
One more feature that I am not sure PostgreSQL has is, row-level,
column-level security. Oracle call this Label-Security in which you
define a policy for certain columns so that they are not visible to
un-authorised users during SELECT queries. This is an important
security
On Aug 4, 2007, at 7:06 , Rohit Khare wrote:
One more feature that I am not sure PostgreSQL has is, row-level,
column-level security. Oracle call this Label-Security in which you
define a policy for certain columns so that they are not visible to
un-authorised users during SELECT queries.
Rohit Khare wrote:
Seeing the history of PostgreSQL development, following features are
expected in pgAdmin:
(1) Facility to insert a column in between other columns during table
design.
(2) Facility to view relationship diagram.
(3) Facility to view table performance level graphically.
Rohit Khare wrote:
I once discussed with you all regarding Oracle's FlashBack Query feature
to recover a database to a certain point of time. That time you all
suggested some indepth cons of this and how it is resource hungry.
One more feature that I am not sure PostgreSQL has is, row-level,
Rohit Khare wrote:
Seeing the history of PostgreSQL development, following features are
expected in pgAdmin:
(1) Facility to insert a column in between other columns during table
design.
This I can see how people like, actually. Theorists claim it's not
needed since column order really
--- Original Message ---
From: Rohit Khare [EMAIL PROTECTED]
To: Dave Page [EMAIL PROTECTED]
Sent: 04/08/07, 12:58:25
Subject: Re: [HACKERS] .NET driver
Seeing the history of PostgreSQL development, following features are
expected in pgAdmin:
I don't see what any of these have
I came across a problem with the log_timezone patch. Given these
conditions:
* log_min_messages is at least debug3
* log_line_prefix includes %t or %m
* log_timezone is not explicitly set in postgresql.conf
the postmaster will dump core during startup, because it tries to format
an elog message
Tom Lane wrote:
I came across a problem with the log_timezone patch. Given these
conditions:
* log_min_messages is at least debug3
* log_line_prefix includes %t or %m
* log_timezone is not explicitly set in postgresql.conf
the postmaster will dump core during startup, because it tries to
On Sat, 2007-04-08 at 09:26 -0400, Andrew Dunstan wrote:
So what are *you* doing about it? This is open source, where if you want
it and it's not there you make it. Otherwise you're just one more
whinger wanting something for nothing.
I don't agree with this attitude at all: we should be
Magnus Hagander [EMAIL PROTECTED] writes:
Any way to tweak this place and have it log in GMT instead, when
log_timezone is NULL?
I think this is just a variant of my #2. The main risk factor IMHO
is that the first call is going to invoke tzload() for the GMT zone
(pgtz does not seem to
On Sat, Aug 04, 2007 at 12:12:46PM -0400, Tom Lane wrote:
There's a value judgment involved here: is it better to print timestamps
in GMT (which the user won't be expecting) than to not print them at all?
I can see arguments on both sides of that.
As long as it's clear that the times are in
Decibel! [EMAIL PROTECTED] writes:
Something else to consider... normally you'd have to have a pretty
serious condition to run into this in normal usage, right? (I doubt
there's many folks that use any debug level, let alone 3) I think that
gives us more flexibility.
Yeah. This whole issue
On Sat, Aug 04, 2007 at 12:46:32PM -0400, Tom Lane wrote:
Decibel! [EMAIL PROTECTED] writes:
Something else to consider... normally you'd have to have a pretty
serious condition to run into this in normal usage, right? (I doubt
there's many folks that use any debug level, let alone 3) I
Neil Conway wrote:
On Sat, 2007-04-08 at 09:26 -0400, Andrew Dunstan wrote:
So what are *you* doing about it? This is open source, where if you want
it and it's not there you make it. Otherwise you're just one more
whinger wanting something for nothing.
I don't agree with this
Comparing with MySQL/FireBird is not to be taken other-wise. Good things
need to be taken care of if they can benefit users. Yes, it is open source
and one can contribute code. But the level of expertise and skill also
matters. PGSQL development community involve experts in the areas of RDBMS,
Decibel! [EMAIL PROTECTED] writes:
Perhaps if we don't have log_timezone set yet we could output something
such as 'LOCALTIME' so that it was obvious. Or maybe output whatever $TZ
is set to?
I think you're confused. This is not a matter of knowing what to print
for the timezone part, it's how
Gregory Stark [EMAIL PROTECTED] writes:
Testers here were having a hard time constructing test cases to reach some
lines touched by the varvarlena patch. Upon further investigation I'm
convinced they're unreachable.
I'm not really happy with any of this patch. ISTM that the stuff you
say is
Greg complained here
http://archives.postgresql.org/pgsql-patches/2007-07/msg00342.php
that the default strategy parameters used by the TOAST compressor
might need some adjustment. After thinking about it a little I wonder
whether they're not even more broken than that. The present behavior
is:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
I'm inclined to think that the concept of force_input_size is wrong.
Instead I suggest that we have a min_comp_rate (minimum percentage
savings) and a min_savings (minimum absolute savings), and compress
if either one is met.
23 matches
Mail list logo
