Bruce Momjian 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 so, perhaps so
Jaime Casanova wrote:
> On Mon, Jul 6, 2009 at 3:15 PM, Bernd Helmle wrote:
> > --On Montag, Juli 06, 2009 13:51:36 -0400 Bruce Momjian
> > wrote:
> >
> >> I think we only completed this for 8.4:
> >>
> >> * Allow "CREATE OR REPLACE VIEW" to add columns to the end
> >> o
Jaime Casanova wrote:
> On Mon, Jul 6, 2009 at 3:15 PM, Bernd Helmle wrote:
> > --On Montag, Juli 06, 2009 13:51:36 -0400 Bruce Momjian
> > wrote:
> >
> >> I think we only completed this for 8.4:
> >>
> >> ? ? ? ? ? ? * Allow "CREATE OR REPLACE VIEW" to add columns to the end
> >> ? ? ? ? ? ? ? ?o
On Mon, Jul 6, 2009 at 3:15 PM, Bernd Helmle wrote:
> --On Montag, Juli 06, 2009 13:51:36 -0400 Bruce Momjian
> 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, t
--On Montag, Juli 06, 2009 13:51:36 -0400 Bruce Momjian
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 change column names
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
>* mod
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 views
* Re: patch: Add columns
Jaime Casanova 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 (pgsql-hackers@postgresql.org)
On Thu, Jul 2, 2009 at 4:50 PM, Tom Lane wrote:
> Alvaro Herrera 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 figu
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 TodoD
Alvaro Herrera 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 retrieved
from CVS his
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?
F
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 s
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
Hi,
I guess todo items marked as [D] (Done) should be removed now... right?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
2009/2/5 Bruce Momjian :
> 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 t
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
> > +---
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
> > +---
> 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 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 functions "seeing"
On Wed, Dec 31, 2008 at 11:04:41AM -0500, Tom Lane wrote:
> Alvaro Herrera 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
Alvaro Herrera 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.
> pg_ca
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
>>
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
+---+--+-
2008/12/31 Tom Lane :
> "Robert Haas" 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 marginal
"Robert Haas" 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, but I remain co
David Fetter 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 indicating "include s
> 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 comman
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 a
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
> di
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
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 h
"Hitoshi Harada" writes:
> 2008/12/30 Tom Lane :
>> 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, so if you have time during
> ti
2008/12/30 Tom Lane :
> 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 support
>
>
"Hitoshi Harada" writes:
> 2008/12/30 Tom Lane :
>> 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 all peers of the
> curre
2008/12/30 Tom Lane :
> Andrew Dunstan 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 pr
"Jaime Casanova" 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 need to follow the same
2008/12/30 Jaime Casanova :
> On Mon, Dec 29, 2008 at 11:59 AM, Tom Lane 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 eithe
Andrew Dunstan 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 without WINDO
2008/12/30 Tom Lane :
> "Hitoshi Harada" 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.112&r2=1.113
>
>> + default framing behavior, which is equivalent to the framing clause
>> + ROWS
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'
On Mon, Dec 29, 2008 at 11:59 AM, Tom Lane 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 do is to
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.
2008/12/29 Tom Lane :
> 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 attribu
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 FUNCT
"Hitoshi Harada" writes:
> 2008/12/29 Tom Lane :
>> * 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 and people decided window f
2008/12/29 Tom Lane :
> 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 wi
"David Rowley" 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 WINDOW
clause ap
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
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 functions. I think this is
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. http://archives.postgresql.org/pgsql-hacker
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
>
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
allow it to be used for all statements with little performance impact
Fix memory leak from exceptions
http://archives.postg
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 it
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
> 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 pro
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
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
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.
---(end of broadcast)
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
* 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 \d
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 s
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?
> >
> >
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? :-
OK, done.
---
Tom Lane wrote:
> Bruce Momjian 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/
Bruce Momjian 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.
You might want to
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
On Sat, Apr 22, 2006 at 05:37:28PM +0200, Gevik Babakhani wrote:
>
> > 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. Th
> 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
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 sequence
2. Fix psql's display
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
>
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
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 JOIN y USING (b) WHERE a=?"
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.use
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
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 o
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.
> o Add PL/PgSQL PROCEDURES th
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:
>
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
NO
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 d
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.
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,co
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 | gr
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
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.
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 c
I am marking the completed TODO items. Are these done?
* Have standalone backend read postgresql.conf
* Prevent whole-row references from leaking memory, e.g. SELECT
COUNT(tab.*)
* Use index to restrict rows returned by multi-key index when used with
no
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 someth
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,
>
Joe Conway wrote:
> 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
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 someo
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 leaki
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
> C
94 matches
Mail list logo
