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
On Sat, Apr 11, 2009 at 07:35:54PM -0400, Tom Lane wrote:
> David Fetter 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
> > win
David Fetter 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 character wider,
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
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 writes:
> > > I assume the 'type' column will identify triggers, i/o functions
> > > (cstring), window functions, and maybe aggregates too; this solves
> > >
On Sat, Apr 11, 2009 at 04:30:02PM -0400, Tom Lane wrote:
> Bruce Momjian 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 cs
Bruce Momjian 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 getting it right i
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 writes:
> > > > Tom, It fits into 80 columns if you don't have any functions with
> > > > 11 parameters. ;-)
> > >
> > > Well, yeah
On Sat, Apr 11, 2009 at 2:47 PM, Josh Berkus 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 wide columns t
David Fetter wrote:
> On Sat, Apr 11, 2009 at 03:12:39PM -0400, Tom Lane wrote:
> > Josh Berkus 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
On Sat, Apr 11, 2009 at 03:12:39PM -0400, Tom Lane wrote:
> Josh Berkus 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 f
Josh Berkus 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 by a new colum
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 afra
Josh Berkus 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 column.
> And
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 th
On Sat, Apr 11, 2009 at 8:58 AM, David Fetter 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
>> wrote:
>> > On 11 Apr 2009, at 08:01, Hitoshi Harada wrote:
>> >> 2009/4/11 David Fetter :
>> >>> On Sat, Apr 11, 2009 at
Sam Mason 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 trigger.
> Wha
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
David Fetter 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
that window
On Sat, Apr 11, 2009 at 10:32:14AM -0400, Tom Lane wrote:
> David Fetter 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, ever
David Fetter 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 latter of whic
2009/4/11 Grzegorz Jaskiewicz :
>
> 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 entitie
On Sat, Apr 11, 2009 at 08:52:31AM -0400, Robert Haas wrote:
> On Sat, Apr 11, 2009 at 5:06 AM, Grzegorz Jaskiewicz
> wrote:
> > On 11 Apr 2009, at 08:01, Hitoshi Harada wrote:
> >> 2009/4/11 David Fetter :
> >>> On Sat, Apr 11, 2009 at 03:48:33PM +0900, Hitoshi Harada wrote:
> Yeah, but all
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', whic
On Sat, Apr 11, 2009 at 5:06 AM, Grzegorz Jaskiewicz
wrote:
> On 11 Apr 2009, at 08:01, Hitoshi Harada wrote:
>> 2009/4/11 David Fetter :
>>> 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 function
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 pg_
2009/4/11 Grzegorz Jaskiewicz :
>
> On 11 Apr 2009, at 08:01, Hitoshi Harada wrote:
>
>> 2009/4/11 David Fetter :
>>>
>>> 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
On 11 Apr 2009, at 08:01, Hitoshi Harada wrote:
2009/4/11 David Fetter :
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 :)
2009/4/11 David Fetter :
> 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 pg_aggreg
On Sat, Apr 11, 2009 at 03:48:33PM +0900, Hitoshi Harada wrote:
> 2009/4/11 Andrew Gierth :
> >> "Tom" == Tom Lane writes:
> >
> > >>> Perhaps more to the point: the previous round of discussion about
> > >>> this already rejected the idea of treating window functions as a
> > >>> category
2009/4/11 Tom Lane :
> Bruce Momjian 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 t
2009/4/11 Andrew Gierth :
>> "Tom" == Tom Lane 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 f
> "Tom" == Tom Lane 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 ha
Tom Lane escreveu:
Bruce Momjian 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 argumen
David Fetter 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, we
>> are n
On Fri, Apr 10, 2009 at 11:30:30AM -0400, Tom Lane wrote:
> David Fetter 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 t
Bruce Momjian 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 --- it seems
Tom Lane wrote:
> David Fetter 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.
David Fetter 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 more to the point:
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 writes:
> > > > > On
On 04/08/09 13:10, Josh Berkus wrote:
On 4/8/09 9:44 AM, Tom Lane wrote:
Josh Berkus 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 thi
On 4/9/09 10:42 AM, Bruce Momjian wrote:
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
Peter Eisentraut 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 fr
Tom Lane wrote:
> Andrew Dunstan writes:
> > Tom Lane wrote:
> >> Peter Eisentraut 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 peopl
Andrew Dunstan writes:
> Tom Lane wrote:
>> Peter Eisentraut 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
Tom Lane wrote:
Peter Eisentraut 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).
Peter Eisentraut 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 this point I'
On Wednesday 08 April 2009 21:56:38 Tom Lane wrote:
> > For my part, I'd like to know what things other than arrays
> > 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 around to impl
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 (pgsq
Josh Berkus 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
> it, we've
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 research
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 f
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 in
On Wed, Apr 8, 2009 at 6:42 PM, Heikki Linnakangas
wrote:
> Dave Page wrote:
>>
>> On Wednesday, April 8, 2009, Josh Berkus 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
Tom Lane wrote:
> Magnus Hagander 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.
Magnus Hagander 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? Where? I didn'
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 f
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 suppor
Heikki Linnakangas wrote:
> Dave Page wrote:
>> On Wednesday, April 8, 2009, Josh Berkus 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 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 http://www.enterprisedb.com
--
Sent via pgsql-hackers
Dave Page wrote:
On Wednesday, April 8, 2009, Josh Berkus 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
NtSetInformationFile() like this:
Heikki Linnakangas 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 subscription:
http://www.postgresql.
Josh Berkus wrote:
On 4/8/09 9:44 AM, Tom Lane wrote:
Josh Berkus 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?
Wel
On Wednesday, April 8, 2009, Josh Berkus wrote:
> On 4/8/09 9:44 AM, Tom Lane wrote:
>
> Josh Berkus 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
On 4/8/09 9:44 AM, Tom Lane wrote:
Josh Berkus 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, Solaris 10 + UFS
Josh Berkus 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
--
Sent via pgsql
On 4/7/09 10:17 PM, Tom Lane wrote:
Robert Haas writes:
On Tue, Apr 7, 2009 at 10:42 PM, Josh Berkus 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 scans?
--
Josh Berkus
PostgreSQL Expert
On Wed, Apr 8, 2009 at 11:59 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Apr 8, 2009 at 10:33 AM, Tom Lane 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,
Robert Haas writes:
> On Wed, Apr 8, 2009 at 10:33 AM, Tom Lane 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 nestloop-over-inner-indexscan case?
W
On Wed, Apr 8, 2009 at 10:33 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Apr 8, 2009 at 1:17 AM, Tom Lane 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
Robert Haas writes:
> On Wed, Apr 8, 2009 at 1:17 AM, Tom Lane 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 scans can't benefit
> from this as
On Wed, Apr 8, 2009 at 1:17 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 7, 2009 at 10:42 PM, Josh Berkus 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 bitm
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 thi
Robert Haas writes:
> On Tue, Apr 7, 2009 at 10:42 PM, Josh Berkus 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 part of
the win anyway. What's le
On Tue, Apr 7, 2009 at 10:42 PM, Josh Berkus 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 mailing li
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 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 writes:
> > > > On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:
> > > >> The \df
Tom Lane wrote:
> Greg Stark writes:
> > On Sun, Apr 5, 2009 at 6:54 PM, Robert Haas 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
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 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, IMH
On Sun, Apr 05, 2009 at 08:55:07PM -0400, Tom Lane wrote:
> David Fetter 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 la
David Fetter 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 02:07:32PM -0400, Tom Lane wrote:
> David Fetter 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 po
Greg Stark writes:
> On Sun, Apr 5, 2009 at 6:54 PM, Robert Haas 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 be
On Sun, Apr 5, 2009 at 6:54 PM, Robert Haas 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 do nothing anyways. I
David Fetter 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 it'd be okay t
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 http://fetter.org/
Phone: +1 415 235 3778
On Sun, Apr 5, 2009 at 12:21 PM, Tom Lane wrote:
> Andrew Dunstan 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 func
Andrew Dunstan 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 proposal
> or di
On Sun, Apr 05, 2009 at 07:55:44AM -0400, Robert Haas wrote:
> On Sun, Apr 5, 2009 at 7:45 AM, Andrew Dunstan 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
> >
Robert Haas wrote:
On Sun, Apr 5, 2009 at 7:45 AM, Andrew Dunstan 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?
On Sun, Apr 5, 2009 at 7:45 AM, Andrew Dunstan 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; the
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 sho
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 cha
92 matches
Mail list logo
