Hi,
Reacting somewhat late, but maybe not too late?
Le 11 avr. 09 à 17:13, Tom Lane a écrit :
My own take on it is that actually I'd prefer one command for all of
these. If I say \df sum it would be good if the output included the
sum() aggregates; the reason being that I might be wondering
2009/4/11 Andrew Gierth and...@tao11.riddles.org.uk:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Perhaps more to the point: the previous round of discussion about
this already rejected the idea of treating window functions as a
category fundamentally separate from plain functions ---
2009/4/11 Tom Lane t...@sss.pgh.pa.us:
Bruce Momjian br...@momjian.us writes:
Yea, I thought we were going to do this:
Please find enclosed one way to handle it, this being prepending
WINDOW to the result types in \df.
but I don't see this behavior in CVS.
IIRC, my original proposal
On Sat, Apr 11, 2009 at 03:48:33PM +0900, Hitoshi Harada wrote:
2009/4/11 Andrew Gierth and...@tao11.riddles.org.uk:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Perhaps more to the point: the previous round of discussion about
this already rejected the idea of treating window functions
2009/4/11 David Fetter da...@fetter.org:
On Sat, Apr 11, 2009 at 03:48:33PM +0900, Hitoshi Harada wrote:
Yeah, but all the window functions are stored in pg_proc.
So are aggregate functions, and they have their own separate way of
being addressed in psql :)
Aggregate functions are stored in
On 11 Apr 2009, at 08:01, Hitoshi Harada wrote:
2009/4/11 David Fetter da...@fetter.org:
On Sat, Apr 11, 2009 at 03:48:33PM +0900, Hitoshi Harada wrote:
Yeah, but all the window functions are stored in pg_proc.
So are aggregate functions, and they have their own separate way of
being
2009/4/11 Grzegorz Jaskiewicz g...@pointblue.com.pl:
On 11 Apr 2009, at 08:01, Hitoshi Harada wrote:
2009/4/11 David Fetter da...@fetter.org:
On Sat, Apr 11, 2009 at 03:48:33PM +0900, Hitoshi Harada wrote:
Yeah, but all the window functions are stored in pg_proc.
So are aggregate
On 11 Apr 2009, at 13:33, Hitoshi Harada wrote:
Maybe trigger functions should be displayed separately too than ?
You don't catch the point. The aggregate entries in pg_proc have
prosrc = 'aggregate_dummy', which means they're dummy and the entities
are stored in pg_aggregate. Triggers in
On Sat, Apr 11, 2009 at 5:06 AM, Grzegorz Jaskiewicz
g...@pointblue.com.pl wrote:
On 11 Apr 2009, at 08:01, Hitoshi Harada wrote:
2009/4/11 David Fetter da...@fetter.org:
On Sat, Apr 11, 2009 at 03:48:33PM +0900, Hitoshi Harada wrote:
Yeah, but all the window functions are stored in pg_proc.
On Sat, Apr 11, 2009 at 01:39:47PM +0100, Grzegorz Jaskiewicz wrote:
On 11 Apr 2009, at 13:33, Hitoshi Harada wrote:
Maybe trigger functions should be displayed separately too than ?
You don't catch the point. The aggregate entries in pg_proc have
prosrc = 'aggregate_dummy', which means
On Sat, Apr 11, 2009 at 08:52:31AM -0400, Robert Haas wrote:
On Sat, Apr 11, 2009 at 5:06 AM, Grzegorz Jaskiewicz
g...@pointblue.com.pl wrote:
On 11 Apr 2009, at 08:01, Hitoshi Harada wrote:
2009/4/11 David Fetter da...@fetter.org:
On Sat, Apr 11, 2009 at 03:48:33PM +0900, Hitoshi Harada
2009/4/11 Grzegorz Jaskiewicz g...@pointblue.com.pl:
On 11 Apr 2009, at 13:33, Hitoshi Harada wrote:
Maybe trigger functions should be displayed separately too than ?
You don't catch the point. The aggregate entries in pg_proc have
prosrc = 'aggregate_dummy', which means they're dummy and
David Fetter da...@fetter.org writes:
On Sat, Apr 11, 2009 at 08:52:31AM -0400, Robert Haas wrote:
We're up to at least four different categories of functions that
people think might require special treatment: window, trigger, I/O,
everything else.
The current psql has \da and \df, the
On Sat, Apr 11, 2009 at 10:32:14AM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Sat, Apr 11, 2009 at 08:52:31AM -0400, Robert Haas wrote:
We're up to at least four different categories of functions that
people think might require special treatment: window, trigger,
I/O,
David Fetter da...@fetter.org writes:
The do nothing solution is unacceptable because windowing functions
behave in a way that's essentially different, from the user's
perspective, from other functions including aggregates.
I don't like doing nothing either, but I disagree with your conclusion
On Sat, Apr 11, 2009 at 11:13:59AM -0400, Tom Lane wrote:
My own take on it is that actually I'd prefer one command for all of
these. If I say \df sum it would be good if the output included the
sum() aggregates; the reason being that I might be wondering if I can
create a plain function
Sam Mason s...@samason.me.uk writes:
On Sat, Apr 11, 2009 at 11:13:59AM -0400, Tom Lane wrote:
If we were designing in a green field I think you could make a real
strong case for a single \df command with an output column type having
the alternatives regular, aggregate, window, and maybe
On Sat, Apr 11, 2009 at 8:58 AM, David Fetter da...@fetter.org wrote:
On Sat, Apr 11, 2009 at 08:52:31AM -0400, Robert Haas wrote:
On Sat, Apr 11, 2009 at 5:06 AM, Grzegorz Jaskiewicz
g...@pointblue.com.pl wrote:
On 11 Apr 2009, at 08:01, Hitoshi Harada wrote:
2009/4/11 David Fetter
All,
Having an extra column in \df for Windowing was rejected out of hand.
Why?
\df (let alone \df+) already displays too many wide columns to fit in
any standard terminal window. You're pretty much forced to use \x
regardless. What's one more column?
And has it occurred to anyone
Josh Berkus j...@agliodbs.com writes:
Having an extra column in \df for Windowing was rejected out of hand.
Why?
I'd definitely support adding it to \df+. Basic \df might be a harder
sell, because it still does mostly fit in 80 columns now, but would
certainly no longer do so with another
Tom,
It fits into 80 columns if you don't have any functions with 11
parameters. ;-)
Actually, I'm thinking the new column ought to be called type. That
way, it could be window or trigger or internal, and more types
later if we develop any (like MED).
Too late for 8.4 I'm afraid, but
Josh Berkus j...@agliodbs.com writes:
Tom,
It fits into 80 columns if you don't have any functions with 11
parameters. ;-)
Well, yeah, but in typical cases I think it fits. A look at the current
regression database shows all but 6 of 117 functions fitting. With
another ten characters eaten
On Sat, Apr 11, 2009 at 03:12:39PM -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Tom, It fits into 80 columns if you don't have any functions with
11 parameters. ;-)
Well, yeah, but in typical cases I think it fits. A look at the
current regression database shows all but
David Fetter wrote:
On Sat, Apr 11, 2009 at 03:12:39PM -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Tom, It fits into 80 columns if you don't have any functions with
11 parameters. ;-)
Well, yeah, but in typical cases I think it fits. A look at the
current
On Sat, Apr 11, 2009 at 2:47 PM, Josh Berkus j...@agliodbs.com wrote:
All,
Having an extra column in \df for Windowing was rejected out of hand.
Why?
I have no idea. I suggested it and the only one I remember speaking
against it was Tom.
\df (let alone \df+) already displays too many
On Sat, Apr 11, 2009 at 03:34:31PM -0400, Bruce Momjian wrote:
David Fetter wrote:
On Sat, Apr 11, 2009 at 03:12:39PM -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Tom, It fits into 80 columns if you don't have any functions with
11 parameters. ;-)
Well, yeah,
Bruce Momjian br...@momjian.us writes:
I assume the 'type' column will identify triggers, i/o functions
(cstring), window functions, and maybe aggregates too; this solves
several problems at once.
+1 for all except i/o functions. The cstring check for that was always
flat-out wrong, and
On Sat, Apr 11, 2009 at 04:30:02PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I assume the 'type' column will identify triggers, i/o functions
(cstring), window functions, and maybe aggregates too; this solves
several problems at once.
+1 for all except i/o functions.
On Sat, Apr 11, 2009 at 01:43:35PM -0700, David Fetter wrote:
On Sat, Apr 11, 2009 at 04:30:02PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I assume the 'type' column will identify triggers, i/o functions
(cstring), window functions, and maybe aggregates too; this
Robert,
For what purpose?
See above, in thread.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David Fetter da...@fetter.org writes:
It occurs to me that we ought to allow for a possibility that a
function can be more than one special case. For example, sum() is
both an aggregate and a windowing function, while rank() is only a
windowing function.
If it makes the display even one
On Sat, Apr 11, 2009 at 07:35:54PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
It occurs to me that we ought to allow for a possibility that a
function can be more than one special case. For example, sum() is
both an aggregate and a windowing function, while rank() is only
On Tue, Apr 07, 2009 at 07:28:25PM -0700, David Fetter wrote:
On Mon, Apr 06, 2009 at 10:51:22PM -0700, David Fetter wrote:
On Sun, Apr 05, 2009 at 05:57:46PM -0700, David Fetter wrote:
On Sun, Apr 05, 2009 at 08:55:07PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
David Fetter da...@fetter.org writes:
Revised patch attached. \dw does not need an 'S' decorator,
Yes it does. We have only painfully gotten to the point of having
consistent behavior across all the \d commands. We are not going
to break that consistency before it's even shipped.
Perhaps
Tom Lane wrote:
David Fetter da...@fetter.org writes:
Revised patch attached. \dw does not need an 'S' decorator,
Yes it does. We have only painfully gotten to the point of having
consistent behavior across all the \d commands. We are not going
to break that consistency before it's even
Bruce Momjian br...@momjian.us writes:
Yea, I thought we were going to do this:
Please find enclosed one way to handle it, this being prepending
WINDOW to the result types in \df.
but I don't see this behavior in CVS.
IIRC, my original proposal involved adding something to the argument
list
On Fri, Apr 10, 2009 at 11:30:30AM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
Revised patch attached. \dw does not need an 'S' decorator,
Yes it does. We have only painfully gotten to the point of having
consistent behavior across all the \d commands. We are not going
David Fetter da...@fetter.org writes:
On Fri, Apr 10, 2009 at 11:30:30AM -0400, Tom Lane wrote:
Perhaps more to the point: the previous round of discussion about
this already rejected the idea of treating window functions as a
category fundamentally separate from plain functions --- that is,
Tom Lane escreveu:
Bruce Momjian br...@momjian.us writes:
Yea, I thought we were going to do this:
Please find enclosed one way to handle it, this being prepending
WINDOW to the result types in \df.
but I don't see this behavior in CVS.
IIRC, my original proposal involved adding
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Perhaps more to the point: the previous round of discussion about
this already rejected the idea of treating window functions as a
category fundamentally separate from plain functions --- that is,
we are not following the aggregate model of
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Here is my thinking, and considering that that would basically involve a
forward-looking design decision right now, I would support dropping the
cardinality() function from 8.4 (if people agree that this is in fact the
design
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Here is my thinking, and considering that that would basically involve a
forward-looking design decision right now, I would support dropping the
cardinality() function from 8.4 (if people
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Here is my thinking, and considering that that would basically involve a
forward-looking design decision right now, I would support dropping the
cardinality() function
On 4/9/09 10:42 AM, Bruce Momjian wrote:
Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
Here is my thinking, and considering that that would basically involve a
forward-looking design decision right now, I would support
On 04/08/09 13:10, Josh Berkus wrote:
On 4/8/09 9:44 AM, Tom Lane wrote:
Josh Berkusj...@agliodbs.com writes:
What about seq scans?
If the kernel can't read-ahead a seqscan by itself, it's unlikely to
be smart enough to be helped by posix_fadvise ... or at least so I
would think. Do you
On Wed, Apr 8, 2009 at 1:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 7, 2009 at 10:42 PM, Josh Berkus j...@agliodbs.com wrote:
So has fadvise been completely dropped from 8.4, or only partially?
Bitmap scans will support it, but index scans
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 8, 2009 at 1:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
And please note that we think bitmap scans are the larger part of
the win anyway. What's left undone there is some marginal mopup.
Can you elaborate on this? I'm fuzzy on why index
On Wed, Apr 8, 2009 at 10:33 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 8, 2009 at 1:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
And please note that we think bitmap scans are the larger part of
the win anyway. What's left undone there is some
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 8, 2009 at 10:33 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The main point is that the planner will prefer a bitmap scan for any
query that's estimated to return more than quite a small number of rows.
That makes sense, but what about the
On Wed, Apr 8, 2009 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 8, 2009 at 10:33 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The main point is that the planner will prefer a bitmap scan for any
query that's estimated to return more than
On 4/7/09 10:17 PM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Tue, Apr 7, 2009 at 10:42 PM, Josh Berkusj...@agliodbs.com wrote:
So has fadvise been completely dropped from 8.4, or only partially?
Bitmap scans will support it, but index scans will not.
What about seq
Josh Berkus j...@agliodbs.com writes:
What about seq scans?
If the kernel can't read-ahead a seqscan by itself, it's unlikely to
be smart enough to be helped by posix_fadvise ... or at least so I
would think. Do you have reason to think differently?
regards, tom lane
On 4/8/09 9:44 AM, Tom Lane wrote:
Josh Berkusj...@agliodbs.com writes:
What about seq scans?
If the kernel can't read-ahead a seqscan by itself, it's unlikely to
be smart enough to be helped by posix_fadvise ... or at least so I
would think. Do you have reason to think differently?
Well,
On Wednesday, April 8, 2009, Josh Berkus j...@agliodbs.com wrote:
On 4/8/09 9:44 AM, Tom Lane wrote:
Josh Berkusj...@agliodbs.com writes:
What about seq scans?
If the kernel can't read-ahead a seqscan by itself, it's unlikely to
be smart enough to be helped by posix_fadvise ... or at
Josh Berkus wrote:
On 4/8/09 9:44 AM, Tom Lane wrote:
Josh Berkusj...@agliodbs.com writes:
What about seq scans?
If the kernel can't read-ahead a seqscan by itself, it's unlikely to
be smart enough to be helped by posix_fadvise ... or at least so I
would think. Do you have reason to think
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
xlog.c now also uses POSIX_FADV_WONTNEED to drop WAL pages from the
OS cache after writing them.
Even when archiving is on?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Dave Page wrote:
On Wednesday, April 8, 2009, Josh Berkus j...@agliodbs.com wrote:
Presumably fadvise is useless on Windows. Anyone know?
It is.
cygwin supports POSIX_FADV_SEQUENTIAL (and POSIX_FADV_NORMAL to revert
it), but not any of the other flags. It maps it to
Kevin Grittner wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
xlog.c now also uses POSIX_FADV_WONTNEED to drop WAL pages from the
OS cache after writing them.
Even when archiving is on?
No, not in that case.
--
Heikki Linnakangas
EnterpriseDB
Heikki Linnakangas wrote:
Dave Page wrote:
On Wednesday, April 8, 2009, Josh Berkus j...@agliodbs.com wrote:
Presumably fadvise is useless on Windows. Anyone know?
It is.
cygwin supports POSIX_FADV_SEQUENTIAL (and POSIX_FADV_NORMAL to revert
it), but not any of the other flags. It maps
Heikki,
It's important to distinguish what kind of fadvise we're talking about.
The bitmap scan code issues hints about individual pages, using
posix_fadvise(... POSIX_FADV_WILLNEED). For increasing the readahead of
a sequential scan, you'd want to use POSIX_FADV_SEQUENTIAL. I believe
the
Josh Berkus wrote:
The other thing I was going to ask you about is using posix_fadvise as
an alternative to O_DIRECT for the xlog. O_DIRECT is, AFAIK,
linux-only, whereas there are direct write fadvise flags which work on
multiple OSes.
What flags are those? I don't see any posix_fadvise
Magnus Hagander mag...@hagander.net writes:
Heikki Linnakangas wrote:
cygwin supports POSIX_FADV_SEQUENTIAL (and POSIX_FADV_NORMAL to revert
it), but not any of the other flags. It maps it to
NtSetInformationFile() like this:
We set this in our open() wrapper in the code today.
Really?
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
Heikki Linnakangas wrote:
cygwin supports POSIX_FADV_SEQUENTIAL (and POSIX_FADV_NORMAL to revert
it), but not any of the other flags. It maps it to
NtSetInformationFile() like this:
We set this in our open() wrapper in the code
On Wed, Apr 8, 2009 at 6:42 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Dave Page wrote:
On Wednesday, April 8, 2009, Josh Berkus j...@agliodbs.com wrote:
Presumably fadvise is useless on Windows. Anyone know?
It is.
cygwin supports POSIX_FADV_SEQUENTIAL (and
Tom,
change cardinality() for multi-dim arrays?
Drop; there's no consensus that this should be changed
Andrew pinged me on this. While there's no consensus that it should be
changed, there's no consensus it shouldn't, either. And once we release
it, we've set the way it operates
On Wed, 8 Apr 2009, Heikki Linnakangas wrote:
Josh Berkus wrote:
The other thing I was going to ask you about is using posix_fadvise as an
alternative to O_DIRECT for the xlog. O_DIRECT is, AFAIK, linux-only,
whereas there are direct write fadvise flags which work on multiple OSes.
What
On Wed, 8 Apr 2009, Tom Lane wrote:
If the kernel can't read-ahead a seqscan by itself, it's unlikely to
be smart enough to be helped by posix_fadvise ... or at least so I
would think.
There's some interesting comments on this subject (and about what fadvise
DONTNEED does) in the RRD
Josh Berkus j...@agliodbs.com writes:
Tom,
change cardinality() for multi-dim arrays?
Drop; there's no consensus that this should be changed
Andrew pinged me on this. While there's no consensus that it should be
changed, there's no consensus it shouldn't, either. And once we release
Tom,
There is no equivalent of multi-dimensional arrays in other kinds of
collections, so I'm not seeing that there is any good guide there.
What else *does* SQL:2008 consider a collection?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list
On Wednesday 08 April 2009 21:56:38 Tom Lane wrote:
For my part, I'd like to know what things other than arrays
collection_expression in the standard applies to. I think the most
sensible course is to make cardinality(array[]) behave consistently with
cardinality(other_stuff) when we get
Peter Eisentraut pete...@gmx.net writes:
Here is my thinking, and considering that that would basically involve a
forward-looking design decision right now, I would support dropping the
cardinality() function from 8.4 (if people agree that this is in fact the
design decision to make).
At
Tom Lane wrote:
Greg Stark st...@enterprisedb.com writes:
On Sun, Apr 5, 2009 at 6:54 PM, Robert Haas robertmh...@gmail.com wrote:
I'm excited about some of them, but not to the point of not wanting to
ship beta. ?So +1 for removing them as per your suggestions.
I'm somewhat excited
On Mon, Apr 06, 2009 at 10:51:22PM -0700, David Fetter wrote:
On Sun, Apr 05, 2009 at 05:57:46PM -0700, David Fetter wrote:
On Sun, Apr 05, 2009 at 08:55:07PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:
The
Tom,
finishing posix_fadvise patch
Push to TODO
So has fadvise been completely dropped from 8.4, or only partially?
change psql's \df output for window functions?
Drop; there's no consensus that this should be changed
Also, Fetter is currently working on a \dw for 8.5.
On Tue, Apr 7, 2009 at 10:42 PM, Josh Berkus j...@agliodbs.com wrote:
Tom,
finishing posix_fadvise patch
Push to TODO
So has fadvise been completely dropped from 8.4, or only partially?
Bitmap scans will support it, but index scans will not.
...Robert
--
Sent via pgsql-hackers
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 7, 2009 at 10:42 PM, Josh Berkus j...@agliodbs.com wrote:
So has fadvise been completely dropped from 8.4, or only partially?
Bitmap scans will support it, but index scans will not.
And please note that we think bitmap scans are the larger
On Tue, Apr 07, 2009 at 07:42:51PM -0700, Josh Berkus wrote:
Tom,
finishing posix_fadvise patch
Push to TODO
So has fadvise been completely dropped from 8.4, or only partially?
change psql's \df output for window functions?
Drop; there's no consensus that this should be
On Sun, Apr 05, 2009 at 05:57:46PM -0700, David Fetter wrote:
On Sun, Apr 05, 2009 at 08:55:07PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:
The \df thing? That's something it'd be okay to revisit during
beta,
Tom Lane wrote:
If there are no objections, I'm going to remove the following items
from the list at
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
change cardinality() for multi-dim arrays?
Drop; there's no consensus that this should be changed
I don't think we
On Sun, Apr 5, 2009 at 7:45 AM, Andrew Dunstan and...@dunslane.net wrote:
Tom Lane wrote:
If there are no objections, I'm going to remove the following items
from the list at
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
change cardinality() for multi-dim arrays?
Drop;
Robert Haas wrote:
On Sun, Apr 5, 2009 at 7:45 AM, Andrew Dunstan and...@dunslane.net wrote:
Tom Lane wrote:
If there are no objections, I'm going to remove the following items
from the list at
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
change cardinality() for
On Sun, Apr 05, 2009 at 07:55:44AM -0400, Robert Haas wrote:
On Sun, Apr 5, 2009 at 7:45 AM, Andrew Dunstan and...@dunslane.net wrote:
Tom Lane wrote:
If there are no objections, I'm going to remove the following items
from the list at
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
Well, it's a compatibility function...
compatible with what?
It's required by the SQL standard.
The other thing that frankly bothers me is that we appear to have
acquired this function by a curious process which involved no
On Sun, Apr 5, 2009 at 12:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
Well, it's a compatibility function...
compatible with what?
It's required by the SQL standard.
The other thing that frankly bothers me is that we appear to
On Sun, Apr 05, 2009 at 12:21:41PM -0400, Tom Lane wrote:
I will leave that item on the Open Items list. I take it no one's
excited about the others?
When the windowing functions become a pain point, let's revisit :)
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone:
David Fetter da...@fetter.org writes:
On Sun, Apr 05, 2009 at 12:21:41PM -0400, Tom Lane wrote:
I will leave that item on the Open Items list. I take it no one's
excited about the others?
When the windowing functions become a pain point, let's revisit :)
The \df thing? That's something
On Sun, Apr 5, 2009 at 6:54 PM, Robert Haas robertmh...@gmail.com wrote:
I'm excited about some of them, but not to the point of not wanting to
ship beta. So +1 for removing them as per your suggestions.
I'm somewhat excited about posix_fadvise but my general feeling was
that it was best to
Greg Stark st...@enterprisedb.com writes:
On Sun, Apr 5, 2009 at 6:54 PM, Robert Haas robertmh...@gmail.com wrote:
I'm excited about some of them, but not to the point of not wanting to
ship beta. So +1 for removing them as per your suggestions.
I'm somewhat excited about posix_fadvise but
On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Sun, Apr 05, 2009 at 12:21:41PM -0400, Tom Lane wrote:
I will leave that item on the Open Items list. I take it no one's
excited about the others?
When the windowing functions become a
David Fetter da...@fetter.org writes:
On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:
The \df thing? That's something it'd be okay to revisit during beta,
IMHO.
OK, I'll work on this tomorrow :)
I think what we were lacking was consensus on what it should do,
not code ...
On Sun, Apr 05, 2009 at 08:55:07PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:
The \df thing? That's something it'd be okay to revisit during
beta, IMHO.
OK, I'll work on this tomorrow :)
I think what we were
If there are no objections, I'm going to remove the following items
from the list at
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
finishing posix_fadvise patch
Push to TODO
change cardinality() for multi-dim arrays?
Drop; there's no consensus that this should be
92 matches
Mail list logo
