Kind people,
I just ran across this, and was wondering whether it's worth a
back-patch. The interval type has an aggregate for average (AVG), but
not one for standard deviation (STDDEV) or variance (VARIANCE).
Is this a bug? Is there some problem with defining variance over
intervals?
TIA for
Tom Lane [EMAIL PROTECTED] writes:
Since when was that a design goal for psql's \d output? We had better
revert the entire pretty-printing patch if you expect this sort of thing
to work reliably. I thought the point of \d formatting was to be
readable, not to be technically the exact same
Since when was that a design goal for psql's \d output? We had better
revert the entire pretty-printing patch if you expect this sort of thing
to work reliably. I thought the point of \d formatting was to be
readable, not to be technically the exact same SQL you'd need to enter.
Hm, I always
Several years ago me and Teodor have proposed partial sort for
top-k ranking result. We have even submitted a very crude patch, but it was
rejected. We use partial sorting extensively in our external application
and found it's very useful. There are many papers recently published about
top-k
David Fetter wrote:
I just ran across this, and was wondering whether it's worth a
back-patch.
New features are not back-patched.
The interval type has an aggregate for average (AVG),
but not one for standard deviation (STDDEV) or variance (VARIANCE).
Is this a bug?
No, it's a missing
Justin Clift wrote:
Bruce Momjian wrote:
If you get full control of PostgreSQL, you can dictate what will happen.
Until then, I will follow the community consensus, which may or may not
match your opinion.
Um, let's take the time to get the features in, otherwise we'll be
waiting another year
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Scott Marlowe wrote:
| On Sun, 2004-07-11 at 19:00, Bruce Momjian wrote:
|
|Andreas Joseph Krogh wrote:
|[ PGP not available, raw data follows ]
|
|-BEGIN PGP SIGNED MESSAGE-
|Hash: SHA1
|
|Hi, I've prepared a patch(against CVS HEAD of today)
On Sun, Jul 11, 2004 at 07:23:13PM -0400, Bruce Momjian wrote:
Were are we on deciding how PREPARE in aborted transactions should behave?
Haven't gotten much further than agreeing that current behaviour is
quirky. It does not follow that we agree it's bad. I would say most
of us agree that
David Fetter [EMAIL PROTECTED] writes:
I just ran across this, and was wondering whether it's worth a
back-patch. The interval type has an aggregate for average (AVG), but
not one for standard deviation (STDDEV) or variance (VARIANCE).
AFAICS, stddev/variance require the concept of
Tom Lane wrote:
AFAICS, stddev/variance require the concept of multiplying two input
values together (square, and also square root, are in the formulas).
I don't know what it means to multiply two intervals --- there's no
such operator in Postgres, anyway.
The problem is not much different
Peter Eisentraut [EMAIL PROTECTED] writes:
The problem is that an interval datum already implies the units, so in
order to allow interval * interval we would have to add a new type
interval squared, which would probably be considered to be a bit
foolish.
Not only foolish but complicated.
On Mon, Jul 12, 2004 at 11:10:34AM -0400, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
The problem is that an interval datum already implies the units,
so in order to allow interval * interval we would have to add a
new type interval squared, which would probably be considered
Our current release schedule is:
o apply most oustanding patches this week
o take two weeks to finalize open issues
o beta August 1
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your
List of open nested transactions items.
Implement named savepoint syntax, with SQL2003 semantics. Work in
progress, foundations done. Needs polishing and testing.
Fix issues with cursors. Need to mess with open portals at subxact abort.
Allow support for exceptions in functions. Allow
Is it really such a good idea to have trust authentication enabled for
localhost (TCP/IP and Unix sockets) by default? Since this pretty much
means that anybody with shell access on the server (which depending on
the situation can be only dba people, or a whole lot of other people as
well) can do
Magnus Hagander [EMAIL PROTECTED] writes:
Is it really such a good idea to have trust authentication enabled for
localhost (TCP/IP and Unix sockets) by default?
No, but none of the others are better. See previous discussions in the
archives. I don't think the situation has changed any since
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Is it really such a good idea to have trust authentication enabled for
localhost (TCP/IP and Unix sockets) by default?
No, but none of the others are better. See previous discussions in the
archives. I don't think the situation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
We currently experience problems while logging into CVS server:
[EMAIL PROTECTED] pgsql75]$ cvs -z3 -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot co
-P pgsql
cvs checkout: authorization failed: server anoncvs.postgresql.org rejected
access
On Mon, 2004-07-12 at 18:49, Bruce Momjian wrote:
Our current release schedule is:
o apply most oustanding patches this week
o take two weeks to finalize open issues
o beta August 1
I will work to support this timeline.
I'm still hacking at the stop-at-point-in-time
Bruce Momjian [EMAIL PROTECTED] writes:
If they supply a password to initdb, shouldn't we then require a
password in pg_hba.conf.
We could, but I'm a bit disturbed about the issues of documenting two
fundamentally different out-of-the-box behaviors. The ensuing confusion
might be worse than
tom lane wrote:
The bottom line to my mind is that if there were a one-size-fits-all
authentication solution, we'd not have so many to choose from. I
don't
think we are doing DBAs any service by pretending that they might not
need to think about their choice of auth method. I could make a
Merlin Moncure [EMAIL PROTECTED] writes:
IMO, forcing su password at initdb time (allowing blank password with a
very stern warning) and bumping localhost to auth is the right way to
go.
This isn't happening for a number of reasons, the most obvious being
that we cannot require initdb to be
Tom Lane wrote:
Andrew Piskorski [EMAIL PROTECTED] writes:
Another thing I've been wondering about, but haven't been able to find
any discussion of:
Just how closely tied is PostgreSQL to its use of shared memory?
Pretty damn closely. You would not be happy with the performance of
anything that
On Tue, Jul 13, 2004 at 10:34:08AM +1200, Oliver Jowett wrote:
Alvaro Herrera wrote:
Fix issues with cursors. Need to mess with open portals at subxact abort.
One quick question here -- how does subtransaction commit interact with
WITHOUT HOLD cursors? I'm hoping they stay open..
That's
It has probably be said before, but new users need
to be able to get up and running on their *development*
system quickly. Throwing new users for a loop with
the password configuration issues would be a problem.
Most people would put up a test server first anyway
in order to check things out and
On Tue, 13 Jul 2004, Justin Clift wrote:
Marc G. Fournier wrote:
Damn ... I'll have to look at it ... we had a hacker get in through the
way anoncvs was setup, so I set a passwd on in /etc/passwd (but didn't
touch the anoncvs setup itself) ... will play with it tonight and see if I
can figure
-bash-2.05b$ cvs up
cvs update: authorization failed: server anoncvs.postgresql.org rejected
access to /projects/cvsroot for user anoncvs
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
No, but none of the others are better. See previous discussions in the
archives. I don't think the situation has changed any since the last
time we hashed this out.
I'll chime in from the phpPgAdmin point of view. The thing with
phpPgAdmin is that it breaks the 'localhost' access is safe rule
No, but none of the others are better. See previous discussions in the
archives. I don't think the situation has changed any since the last
time we hashed this out.
If they supply a password to initdb, shouldn't we then require a
password in pg_hba.conf.
This is further to my previous suggestion
temporarily while I figure out what I screwed up that allowed a hacker to
make use of he anoncvs account :( and, no, anoncvs doesn't have access to
the core cvsroot ...
On Tue, 13 Jul 2004, Christopher Kings-Lynne wrote:
-bash-2.05b$ cvs up
cvs update: authorization failed: server
Marc G. Fournier wrote:
temporarily while I figure out what I screwed up that allowed a hacker
to make use of he anoncvs account :( and, no, anoncvs doesn't have
access to the core cvsroot ...
Did it have anything to do with this CERT advisory?
31 matches
Mail list logo
