Jaime Casanova wrote:
Hi,
This one is still in the TODO (and marked as not done). but i think
this is partially done (at least the last entry should be removed),
right?
Improve ability to modify views via ALTER TABLE
* Re: idea: storing view source in system catalogs
* modifying
--On Montag, Juli 06, 2009 13:51:36 -0400 Bruce Momjian br...@momjian.us
wrote:
I think we only completed this for 8.4:
* Allow CREATE OR REPLACE VIEW to add columns to the end
of a view (Robert Haas)
Yes, this is done, but we're still not able to drop or
On Mon, Jul 6, 2009 at 3:15 PM, Bernd Helmlemaili...@oopsware.de wrote:
--On Montag, Juli 06, 2009 13:51:36 -0400 Bruce Momjian br...@momjian.us
wrote:
I think we only completed this for 8.4:
* Allow CREATE OR REPLACE VIEW to add columns to the end
of a view
Jaime Casanova wrote:
On Mon, Jul 6, 2009 at 3:15 PM, Bernd Helmlemaili...@oopsware.de wrote:
--On Montag, Juli 06, 2009 13:51:36 -0400 Bruce Momjian br...@momjian.us
wrote:
I think we only completed this for 8.4:
? ? ? ? ? ? * Allow CREATE OR REPLACE VIEW to add columns to the end
Jaime Casanova wrote:
On Mon, Jul 6, 2009 at 3:15 PM, Bernd Helmlemaili...@oopsware.de wrote:
--On Montag, Juli 06, 2009 13:51:36 -0400 Bruce Momjian br...@momjian.us
wrote:
I think we only completed this for 8.4:
* Allow CREATE OR REPLACE VIEW to add columns to the end
Bruce Momjian br...@momjian.us wrote:
The problem is that third item is an email subject, not text we can
typically modify.
Is it really more important that the line in the TODO list reflect the
subject line of the referenced email than that it accurately describe
the work we want done? If
Jaime Casanova wrote:
Hi,
I guess todo items marked as [D] (Done) should be removed now... right?
Would there be some value in creating a new page TodoDone84 and moving
those items to it?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company -
On Thu, 2009-07-02 at 17:29 -0400, Alvaro Herrera wrote:
Jaime Casanova wrote:
Hi,
I guess todo items marked as [D] (Done) should be removed now... right?
Would there be some value in creating a new page TodoDone84 and moving
those items to it?
For historical record I could see
Joshua D. Drake wrote:
On Thu, 2009-07-02 at 17:29 -0400, Alvaro Herrera wrote:
Jaime Casanova wrote:
Hi,
I guess todo items marked as [D] (Done) should be removed now... right?
Would there be some value in creating a new page TodoDone84 and moving
those items to it?
Alvaro Herrera alvhe...@commandprompt.com writes:
Jaime Casanova wrote:
I guess todo items marked as [D] (Done) should be removed now... right?
Would there be some value in creating a new page TodoDone84 and moving
those items to it?
In the past we've figured that old TODO versions could be
Andrew Dunstan wrote:
Joshua D. Drake wrote:
On Thu, 2009-07-02 at 17:29 -0400, Alvaro Herrera wrote:
Jaime Casanova wrote:
I guess todo items marked as [D] (Done) should be removed now... right?
Would there be some value in creating a new page TodoDone84 and moving
those
On Thu, Jul 2, 2009 at 4:50 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Jaime Casanova wrote:
I guess todo items marked as [D] (Done) should be removed now... right?
Would there be some value in creating a new page TodoDone84 and moving
those items
Jaime Casanova jcasa...@systemguards.com.ec writes:
We want to use the same format/sections like in the TODO?
Sure, why not? Just copy the page and strip out the not-done items.
No reason to think hard here.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Robert Haas wrote:
I am not thrilled about inventing a new column for this, but how about
a display like so:
regression=# \df nth_value
List of functions
Schema | Name| Result data type | Argument data types
2009/2/5 Bruce Momjian br...@momjian.us:
Robert Haas wrote:
I am not thrilled about inventing a new column for this, but how about
a display like so:
regression=# \df nth_value
List of functions
Schema | Name| Result data type | Argument data
Robert Haas wrote:
I am not thrilled about inventing a new column for this, but how about
a display like so:
regression=# \df nth_value
List of functions
Schema | Name| Result data type | Argument data types
Hi,
Happy new year!
Le 31 déc. 08 à 17:04, Tom Lane t...@sss.pgh.pa.us a écrit :
However, it seems kind of inconsistent to do this for window functions
unless we also make \df start putting parens around the argument lists
for regular functions. Comments?
A way to distinguish between window
I am not thrilled about inventing a new column for this, but how about
a display like so:
regression=# \df nth_value
List of functions
Schema | Name| Result data type | Argument data types
2008/12/31 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
Apparently that analogy didn't impress anyone but me.
It impressed me. I liked making WINDOW a flag that occurs later in
the statement a lot better.
I ended up going with the flag/attribute approach. The
Tom Lane wrote:
I am not thrilled about inventing a new column for this, but how about
a display like so:
regression=# \df nth_value
List of functions
Schema | Name| Result data type | Argument data types
Heikki Linnakangas escribió:
Tom Lane wrote:
I am not thrilled about inventing a new column for this, but how about
a display like so:
regression=# \df nth_value
List of functions
Schema | Name| Result data type | Argument data types
Alvaro Herrera alvhe...@commandprompt.com writes:
Heikki Linnakangas escribió:
Tom Lane wrote:
pg_catalog | nth_value | anyelement | anyelement, integer OVER window
That looks like OVER window is associated with the integer, like
DEFAULT. I don't have any better suggestions, though.
On Wed, Dec 31, 2008 at 11:04:41AM -0500, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Heikki Linnakangas escribi�:
Tom Lane wrote:
pg_catalog | nth_value | anyelement | anyelement, integer OVER
window
That looks like OVER window is associated with the
I wrote:
You could certainly argue the classification either way, but I think
that we should make a hard decision now: either window functions are
treated as a distinct object type (implying their own set of command
names and nuisance errors if you use the wrong one), or they are not a
On Tue, Dec 30, 2008 at 11:59:22AM -0500, Tom Lane wrote:
I wrote:
You could certainly argue the classification either way, but I
think that we should make a hard decision now: either window
functions are treated as a distinct object type (implying their
own set of command names and
Apparently that analogy didn't impress anyone but me. AFAICT the
majority opinion is that we should use the syntax
create [or replace] [window] function ...
but just ignore the distinction between regular functions and window
functions for all other function-related SQL commands.
David Fetter da...@fetter.org writes:
Presumably psql should know about this change. Should \df now include
windowing functions along with a boolean column that indicates whether
a function is a windowing function? Should there be \dw[+] instead?
In either case, should the S option
Robert Haas robertmh...@gmail.com writes:
Apparently that analogy didn't impress anyone but me.
It impressed me. I liked making WINDOW a flag that occurs later in
the statement a lot better.
I ended up going with the flag/attribute approach. The other would be
only marginally more work now,
Hitoshi Harada umi.tan...@gmail.com writes:
2008/12/29 Tom Lane t...@sss.pgh.pa.us:
* Support creation of user-defined window functions. I think this is
a must have for 8.4 --- we are not in the habit of building
nonextensible basic features. It doesn't seem that hard either.
The reason I
I wrote:
* Support creation of user-defined window functions. I think this is
a must have for 8.4 --- we are not in the habit of building
nonextensible basic features. It doesn't seem that hard either.
I think all we need do is to allow WINDOW as an attribute keyword
in CREATE FUNCTION.
2008/12/29 Tom Lane t...@sss.pgh.pa.us:
I wrote:
* Support creation of user-defined window functions. I think this is
a must have for 8.4 --- we are not in the habit of building
nonextensible basic features. It doesn't seem that hard either.
I think all we need do is to allow WINDOW as an
Tom Lane wrote:
However, if we do that then for consistency we'd have to invent
DROP WINDOW FUNCTION, ALTER WINDOW FUNCTION, RENAME WINDOW FUNCTION,
COMMENT ON WINDOW FUNCTION, yadda yadda, and insist that you refer
to a function properly (with or without WINDOW) in each one of these
commands.
On Mon, Dec 29, 2008 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
* Support creation of user-defined window functions. I think this is
a must have for 8.4 --- we are not in the habit of building
nonextensible basic features. It doesn't seem that hard either.
I think all we need
I wrote:
* Investigate whether we should prohibit window functions in recursive
terms; check whether any of the committed prohibitions are unnecessary.
I looked into these questions a bit. As for the first, there doesn't
appear to be a compelling implementation reason to forbid it, and I
can't
2008/12/30 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
And surveying sgml docs, I found this is not correct.
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/select.sgml?r1=1.112r2=1.113
+ default framing behavior, which is equivalent to the
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
However, if we do that then for consistency we'd have to invent
DROP WINDOW FUNCTION, ALTER WINDOW FUNCTION, RENAME WINDOW FUNCTION,
COMMENT ON WINDOW FUNCTION, yadda yadda, and insist that you refer
to a function properly (with or
2008/12/30 Jaime Casanova jcasa...@systemguards.com.ec:
On Mon, Dec 29, 2008 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
* Support creation of user-defined window functions. I think this is
a must have for 8.4 --- we are not in the habit of building
nonextensible basic features.
Jaime Casanova jcasa...@systemguards.com.ec writes:
i don't understand this window function stuff well yet, but AFAIU it
is like an aggregate function that shows grouped values without
grouping rows (ok, maybe a very laizy or novice definition) but if
that is correct or near correct maybe we
2008/12/30 Tom Lane t...@sss.pgh.pa.us:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
However, if we do that then for consistency we'd have to invent
DROP WINDOW FUNCTION, ALTER WINDOW FUNCTION, RENAME WINDOW FUNCTION,
COMMENT ON WINDOW FUNCTION, yadda yadda, and insist that you
Hitoshi Harada umi.tan...@gmail.com writes:
2008/12/30 Tom Lane t...@sss.pgh.pa.us:
What is the difference? AFAICS the RANGE and ROWS keywords ought to be
equivalent if you are not specifying expression PRECEDING or
expression FOLLOWING.
The difference is that RANGE ... CURRENT ROW contains
2008/12/30 Tom Lane t...@sss.pgh.pa.us:
Hah, I had missed that fine point. Okay, doc is wrong and I will fix.
Given that, I think that a suitable minimum implementation should cover
both the RANGE/ROWS distinction and the CURRENT ROW/UNBOUNDED FOLLOWING
distinction, ie I would like 8.4 to
Hitoshi Harada umi.tan...@gmail.com writes:
2008/12/30 Tom Lane t...@sss.pgh.pa.us:
Is this something you're interested in working on? I can tackle it
if you don't have time now.
Sorry, over the new year days, I don't have time and will be remote.
Maybe from 3th or 4th I can work on this,
Tom Lane escribió:
The core window-functions patch is now committed and ready for wider
testing. However, there are a number of unfinished items, at least
some of which I'd like to see addressed before 8.4 release. In rough
order of importance:
[lots of discussion]
Perhaps I was a bit
On Mon, 2008-12-29 at 12:35 -0500, Tom Lane wrote:
we could lock the rows. However, consider something like this:
select x, lead(x) over() from table for update limit 1;
Because of the LIMIT, we'd only lock the first-returned row ...
but the values returned would also depend on the
Tom Lane Wrote:
The core window-functions patch is now committed and ready for wider
testing. However, there are a number of unfinished items, at least
some of which I'd like to see addressed before 8.4 release. In rough
order of importance:
* Support creation of user-defined window
David Rowley dgrow...@gmail.com writes:
Unsure how difficult it is, maybe another one for a TODO, 8.4 or 8.5 I'm not
sure:
* Minimise sorts in a query such as:
I'm not tremendously excited about improving that situation. As the
code stands, the user can control what happens by ordering the
2008/12/29 Tom Lane t...@sss.pgh.pa.us:
The core window-functions patch is now committed and ready for wider
testing. However, there are a number of unfinished items, at least
some of which I'd like to see addressed before 8.4 release. In rough
order of importance:
* Support creation of
Thanks, removed.
---
Simon Riggs wrote:
These two items are complete in 8.2, IIRC
Allow constraint_exclusion to work for UNIONs like it does for
inheritance, allow it to work for UPDATE and DELETE statements, and
On Fri, 2007-01-12 at 22:24 +, Simon Riggs wrote:
This item was rejected by Tom, since a workaround exists
Add estimated_count(*) to return an estimate of COUNT(*)
This would use the planner ANALYZE statistics to return an estimated
count.
Gevik Babakhani wrote:
Please accept my apologies for this trivial question...
I have been reading through the TODO items for the last couple of days
and I couldn't stop wondering whether there is history of discussion
kept or logged about the TODO items somewhere.
Not really, though the CVS
On Wed, Apr 26, 2006 at 11:44:52PM +0200, Gevik Babakhani wrote:
Please accept my apologies for this trivial question...
I have been reading through the TODO items for the last couple of days
and I couldn't stop wondering whether there is history of discussion
kept or logged about the TODO
Not really, though the CVS history shows when the item was added. Many
items represent complex threads of discussion, so only the general
conclusion is in the TODO list. Is there an items that is unclear?
The reason I asked this question is because I would like to contribute.
In fact I
Gevik Babakhani wrote:
Not really, though the CVS history shows when the item was added. Many
items represent complex threads of discussion, so only the general
conclusion is in the TODO list. Is there an items that is unclear?
The reason I asked this question is because I would like to
Thank you :)
On Wed, 2006-04-26 at 18:14 -0400, Bruce Momjian wrote:
Gevik Babakhani wrote:
Not really, though the CVS history shows when the item was added. Many
items represent complex threads of discussion, so only the general
conclusion is in the TODO list. Is there an items that
On Saturday 22 April 2006 13:34, Tom Lane wrote:
Also, the TODO item could be worded
* Make psql's \d commands more consistent
because that's really what Neil is on about ...
like making \df only show user functions and \dfS show system functions, like
all the other objects? :-)
--
On Saturday 22 April 2006 11:24, Alvaro Herrera wrote:
Dhanaraj M wrote:
I saw the following in the TODO list. I am currently trying to work on
them. I could not understand clearly what needs to be done. Can anybody
give me the details for the following so that I can work on?
Robert Treat wrote:
On Saturday 22 April 2006 11:24, Alvaro Herrera wrote:
Dhanaraj M wrote:
I saw the following in the TODO list. I am currently trying to work on
them. I could not understand clearly what needs to be done. Can anybody
give me the details for the following so that I
* Robert Treat ([EMAIL PROTECTED]) wrote:
On Saturday 22 April 2006 13:34, Tom Lane wrote:
Also, the TODO item could be worded
* Make psql's \d commands more consistent
because that's really what Neil is on about ...
like making \df only show user functions and \dfS show system
On Sunday 23 April 2006 11:42, Alvaro Herrera wrote:
Robert Treat wrote:
On Saturday 22 April 2006 11:24, Alvaro Herrera wrote:
Dhanaraj M wrote:
I saw the following in the TODO list. I am currently trying to work
on them. I could not understand clearly what needs to be done. Can
Dhanaraj M wrote:
I saw the following in the TODO list. I am currently trying to work on them.
I could not understand clearly what needs to be done. Can anybody give me
the details for the following so that I can work on?
clients-psql
=
1. Have psql show current values for a
This one means when you do a \dt of a sequence, add a column to display
the current value.
Perhaps this one will be tricky because you will never be sure to get
the last sequence number when you query for it. The number could change
the moment the query is finished.
Dhanaraj M wrote:
I saw the following in the TODO list. I am currently trying to work on them.
I could not understand clearly what needs to be done. Can anybody give me
the details for the following so that I can work on?
clients-psql
=
1. Have psql show current values for a
Bruce Momjian pgman@candle.pha.pa.us writes:
but that was not clear. TODO is now:
o Fix psql's \dn for various schema combinations (Neil)
http://archives.postgresql.org/pgsql-hackers/2004-11/msg00014.php
with a URL that has the details. Thanks for pointing out the problem.
OK, done.
---
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
but that was not clear. TODO is now:
o Fix psql's \dn for various schema combinations (Neil)
Bruce Momjian [EMAIL PROTECTED] writes:
. Allow multi-column indexes to be used to optimize row-value expressions. Ie,
allow a btree index on a,b to be used to execute an expression like (a,b)
(x,y).
I have not heard of any of those so I have not been actively excluding
them from
Greg Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
TODO item?
On that note several prior conversations I had here ended with WIBNI
conclusions that really ought to be TODO items, in my humble opinion. Two come
to mind off the top of my head resulting in:
. SELECT * FROM x
Bruce Momjian wrote:
I am marking the completed TODO items. Are these done?
Can we mark this one complete?
* Allow easy display of usernames in a group
regression=# SELECT g.grosysid, g.groname, s.usesysid, s.usename FROM
pg_shadow s, pg_group g WHERE s.usesysid = any (g.grolist);
grosysid |
Bruce Momjian [EMAIL PROTECTED] writes:
* Use index to restrict rows returned by multi-key index when used with
non-consecutive keys or OR clauses, so fewer heap accesses
Not sure what this means.
This is a Vadim idea. The idea was that if you had a multi-key index on
col1,col2,col3, and
Josh Berkus wrote:
Bruce,
o Allow array declarations and other data types in PL/PgSQL DECLARE
o Allow PL/PgSQL to support array element assignment
AFAIK, these two are not done, but they are redundant. Either one requires
the implementation of the other.
OK.
Josh Berkus wrote:
o Allow array declarations and other data types in PL/PgSQL DECLARE
o Allow PL/PgSQL to support array element assignment
AFAIK, these two are not done, but they are redundant. Either one requires
the implementation of the other.
They are done (at least the array
Tom Lane kirjutas R, 08.08.2003 kell 16:56:
Bruce Momjian [EMAIL PROTECTED] writes:
o Add optional textual message to NOTIFY
Not done, but there is room in the FE/BE protocol now for something like
this.
Were there any other changes to NOTIFY - there was talk about making
NOTIFY
Josh Berkus wrote:
Joe,
They are done (at least the array declarations and array element
assignment part):
Way cool! How'd I miss that one?
Time to test
o Add PL/PgSQL PROCEDURES that can return multiple values
Hmmm ... I know how this got on the TODO, but it's
No, I don't think any of that was done, particularly because there was
no discussion of the implemention.
---
Hannu Krosing wrote:
Tom Lane kirjutas R, 08.08.2003 kell 16:56:
Bruce Momjian [EMAIL PROTECTED] writes:
Bruce,
Actually, now that I look at it again, it is referring to procedures,
not functions. Maybe just make it:
o Add capability to create and call PROCEDURES
OK. I need to put a full proposal behind this once 7.4 is in the can.
However, this is largely academic until we get
Joe Conway wrote:
Bruce Momjian wrote:
I am marking the completed TODO items. Are these done?
Can we mark this one complete?
* Allow easy display of usernames in a group
regression=# SELECT g.grosysid, g.groname, s.usesysid, s.usename FROM
pg_shadow s, pg_group g WHERE s.usesysid =
Joe,
They are done (at least the array declarations and array element
assignment part):
Way cool! How'd I miss that one?
Time to test
o Add PL/PgSQL PROCEDURES that can return multiple values
Hmmm ... I know how this got on the TODO, but it's a fragment of a larger
Bruce Momjian wrote:
o Add PL/PgSQL PROCEDURES that can return multiple values
Do you have TODO to add for this? I removed the original one because,
as worded, it was complete.
Actually, now that I look at it again, it is referring to procedures,
not functions. Maybe just make it:
o Add
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
This one I don't understand:
o Support construction of array result values in expressions
Not sure why you don't understand it, when you did it ;-). It's asking
for the ARRAY[] syntax. Bruce, that one should be marked done.
Updated
Bruce Momjian [EMAIL PROTECTED] writes:
I am marking the completed TODO items. Are these done?
* Have standalone backend read postgresql.conf
[looks] Nope. No ProcessConfigFile() call in postgres.c.
* Prevent whole-row references from leaking memory, e.g. SELECT
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am marking the completed TODO items. Are these done?
* Have standalone backend read postgresql.conf
[looks] Nope. No ProcessConfigFile() call in postgres.c.
OK.
* Prevent whole-row references from leaking memory,
Josh Berkus wrote:
Actually, now that I look at it again, it is referring to procedures,
not functions. Maybe just make it:
o Add capability to create and call PROCEDURES
OK. I need to put a full proposal behind this once 7.4 is in the can.
However, this is largely academic until we get
OK, TODO updated.
---
Joe Conway wrote:
Bruce Momjian wrote:
o Add PL/PgSQL PROCEDURES that can return multiple values
Do you have TODO to add for this? I removed the original one because,
as worded, it
Joe Conway [EMAIL PROTECTED] writes:
This one I don't understand:
o Support construction of array result values in expressions
Not sure why you don't understand it, when you did it ;-). It's asking
for the ARRAY[] syntax. Bruce, that one should be marked done.
I thought Peter did something
83 matches
Mail list logo
