Thread: PostgreSQL roadmap for 8.2 and beyond.
Autovacuum is getting put into the 8.1 release which
is awesome. A lot of us are wondering now that
PostgreSQL has all the features that many of us need,
what are the features being planned for future
releases?
What do you see for 8.2 and beyond? What type of
features are you devs planning for 9.0? It would be
good if you could put up a place on your site so we
mortals can drool over up-coming postgresql features.
__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs
On Fri, 2005-10-14 at 09:57 -0700, karen hill wrote: > Autovacuum is getting put into the 8.1 release which > is awesome. A lot of us are wondering now that > PostgreSQL has all the features that many of us need, > what are the features being planned for future > releases? You know, as PostgreSQL becomes more advanced I find the features on my "wanted" list growing instead of shrinking. The reason for this is that I use it in wider and more varied situations. I am fairly sure there are easily 5 years worth of work remaining at the current development pace. > What do you see for 8.2 and beyond? What type of > features are you devs planning for 9.0? It would be Here is a summary of the last time this question was asked. Around when 8.0 was about to be released so a small percentage of these might be done. Of course, there is also everything in the TODO list and a large part of the SQL Specs to be implemented on top of all of the below. http://www.postgresql.org/docs/faqs.TODO.html http://www.postgresql.org/docs/8.0/interactive/unsupported-features-sql-standard.html Dave Fetter: * optional interface which sends a row typeoid along with each row in a result set * morevisibility from RULEs into the expression tree generated by the parser and/or other RULEs * SQL/MED (or atleast things that would make it easier to implement) * Debugging hooks into all the PLs * Some way ofestimating a "query progress meter" for long-running queries * MULTISET, COLLECT, UNNEST, FUSION, INTERSECT MERGE! MERGE! MERGE! MERGE! MERGE! MERGE! Gavin Sherry: Grouping sets Recursive queries Window functions Updatable views Updatable cursors Materialised views Debug-able PL/PgSQL -- EXPLAIN [ANALYZE] functionality, step through? Costestimation for functions -- perhaps a pipe dream, I know Performance: Better bulk load 'Continuous' vacuum at a fraction of the IO cost of normal vacuum Multimaster replication General OLTPthroughput improvements -- where and how, I'm not sure. Indexes: Bitmap indexes (as opposedto bitmap scans) Merlin Moncure: 1. Proper row constructor, such that select (1,2,1) > (2,1,1); returns the right answer, and select * from t where (t1,t2,t3) > (c1, c2, c3) order by t1,t2,t3 limit 1 returnsthe right answer and uses a index on t1,t2,t3 if it exists. this is on the TODO. 2.In the planner, a parameterized limit for prepared statements to assume a small value (like 1). 3. Ability to create arrays of composite types (and nest them). William Zhang: * Updatable Views per SQL * INTERVAL data type per SQL * BLOB/CLOB data type per SQL * Faster bulk load * Remove "current transaction is aborted, commands ignored ..." * Compile with MSVC onWin32 platforms. MySQL support it. * Thread safety libpq, ecpg. Chris Browne: - Vacuum Space Map - Maintain a map of recently-expired rows This allows vacuum to targetspecific pages for possible free space without requiring a sequential scan. - Deferrableunique constraint - Probably trivially easy would be to add an index to pg_listener - Tougher but better would be to have pg_listener be an in-memory structure rather than being physicallyrepresented as a table - MERGE / UPSERT - Config file "#includes" for postgresql.conf,pg_hba.conf - Some better ability to terminate backends - Automatically updatableviews (per SQL 99) Ron Mayer: Standards stuff: * Updateable views (easier to use Ruby/Rails's ActiveRecord on legacydata) * The elementary OLAP stuff Contrib related stuff: * Contrib/xml2 workingwith XML Namespaces. * Some sort of GIST index for querying XML data (XPath? SQL/XML?) * The array functions and indexes from contrib/intarray and contrib/intagg made more general to work with other data types. (I find these contrib modules quite useful) Annoyances: * more sanemath with intervals. For example, try: select '0.01 years'::interval, '0.01 months'::interval; Ease of use: * Nice defaults for autovacuum and checkpoints and bgwriter that automatically avoidbig I/O spikes by magically distributing I/O in a nice way. Easier COPY for client library authors: * A way to efficiently insert many values like COPY from STDIN from client libraries thatdon't support COPY from STDIN. Perhaps it could happen through the apparently standards compliant "INSERT INTO table VALUES (1,2),(3,4),(5,6)" [feature id F641] or perhaps through anew COPY tablename FROM STRING 'a big string instead of stdin' feature that would be easier for clientsto support? It seems in most new client libraries COPY FROM STDIN stays broken for quitea long time. Would a alternative COPY FROM A_BIG_STRING be easier for them to support and thereforeavailable more often? Meta-stuff * A failover plus load-balancing (pgpool+slony?) installer for dummies that handles simple cases. * A single place to find all the useful non-corestuff like projects on pgfoundry, gborg, contrib, and various other places around the net (PL/RPL/Ruby Postgis). Perhaps if the postgresql website had a small wiki somewhere where anyone couldadd links with a short description to any such projects it'd be easier to know what's out there... * Nice APIs and documentation [probably already exists] to continue encouraging projectslike PostGIS and PL/R that IMHO are the biggest advantage of postgresql over the commercial vendors'offerings. Heikki Linnakangas: * concurrent, partial vacuum that would for example only scan pages that happen tobe in memory * index-only scans * database assertions * lightwight PITR that wouldn't requireto shut down and restore a backup. I'm thinking something like "REWIND TO xid 12345". It could be implemented by just setting already-committed transactions as aborted in the clog (vacuum and commitstatus hint bits need to be disabled beforehand). This would be very handy for automatic regression testing applications. You could load the test database just once, then run test case, rewind, run another test case, rewind and so on. As more disruptive longer-term things: * multiple alternativeaccess plans for prepared statements. For example, if you have a query like "SELECT * FROM historyWHERE timestamp BETWEEN ? AND ?", the optimal access plan depends a lot on the parameters. Postgres could keep all the plans that are optimal for some combination of parameters, and choose themost efficient one at execution time depending on the parameters. The execution side would actually be quite simple to implement. Introduce a new conditional node type that has > 1 child nodes, and acondition that is evaluated at execution time and determines which child node to use. Determining the conditionswould require big changes to the planner and estimation routines. * support for TutorialD as an alternative to SQL. It would be great for educational purposes. My own wish list: * Identity/generator support (per standard) * Merge (update/insert as required) * Multi-CPUsorts. Take a large single sort like an index creation and split the work among multiple CPUs. --
Don't forget insert/update returning. With the deprecation of OID's this functionality is becoming more and more important when using custom types and column defaults. Some method for plpgsql to handle the result sets returned and save to a variable would be important for this feature too. Select into works but it would be silly to see something like select a into somevariable from (insert into tablename (a) default values returning a) instead of an extension to the insert statement itself. Kevin McArthur ----- Original Message ----- From: "Rod Taylor" <pg@rbt.ca> To: "karen hill" <karen_hill22@yahoo.com> Cc: <pgsql-hackers@postgresql.org> Sent: Saturday, October 15, 2005 6:16 PM Subject: Re: [HACKERS] PostgreSQL roadmap for 8.2 and beyond. > On Fri, 2005-10-14 at 09:57 -0700, karen hill wrote: >> Autovacuum is getting put into the 8.1 release which >> is awesome. A lot of us are wondering now that >> PostgreSQL has all the features that many of us need, >> what are the features being planned for future >> releases? > > You know, as PostgreSQL becomes more advanced I find the features on my > "wanted" list growing instead of shrinking. > > The reason for this is that I use it in wider and more varied > situations. > > I am fairly sure there are easily 5 years worth of work remaining at the > current development pace. > >> What do you see for 8.2 and beyond? What type of >> features are you devs planning for 9.0? It would be > > Here is a summary of the last time this question was asked. Around when > 8.0 was about to be released so a small percentage of these might be > done. > > Of course, there is also everything in the TODO list and a large part of > the SQL Specs to be implemented on top of all of the below. > > http://www.postgresql.org/docs/faqs.TODO.html > http://www.postgresql.org/docs/8.0/interactive/unsupported-features-sql-standard.html > > > Dave Fetter: > * optional interface which sends a row typeoid along with each > row in a result set > * more visibility from RULEs into the expression tree generated > by the parser and/or other RULEs > * SQL/MED (or at least things that would make it easier to > implement) > * Debugging hooks into all the PLs > * Some way of estimating a "query progress meter" for > long-running queries > * MULTISET, COLLECT, UNNEST, FUSION, INTERSECT > > MERGE! MERGE! MERGE! MERGE! MERGE! MERGE! > > Gavin Sherry: > Grouping sets > Recursive queries > Window functions > Updatable views > Updatable cursors > Materialised views > Debug-able PL/PgSQL -- EXPLAIN [ANALYZE] functionality, step > through? > Cost estimation for functions -- perhaps a pipe dream, I know > > Performance: > > Better bulk load > 'Continuous' vacuum at a fraction of the IO cost of normal > vacuum > Multimaster replication > General OLTP throughput improvements -- where and how, I'm not > sure. > > Indexes: > > Bitmap indexes (as opposed to bitmap scans) > > Merlin Moncure: > 1. Proper row constructor, such that > select (1,2,1) > (2,1,1); > returns the right answer, > and > select * from t where (t1,t2,t3) > (c1, c2, c3) order by > t1,t2,t3 limit > 1 > returns the right answer and uses a index on t1,t2,t3 if it > exists. > > this is on the TODO. > > 2. In the planner, a parameterized limit for prepared statements > to > assume a small value (like 1). > > 3. Ability to create arrays of composite types (and nest them). > > William Zhang: > * Updatable Views per SQL > * INTERVAL data type per SQL > * BLOB/CLOB data type per SQL > * Faster bulk load > * Remove "current transaction is aborted, commands ignored ..." > * Compile with MSVC on Win32 platforms. MySQL support it. > * Thread safety libpq, ecpg. > > Chris Browne: > - Vacuum Space Map - Maintain a map of recently-expired rows > > This allows vacuum to target specific pages for possible > free > space without requiring a sequential scan. > > - Deferrable unique constraint > > - Probably trivially easy would be to add an index to > pg_listener > > - Tougher but better would be to have pg_listener be an > in-memory > structure rather than being physically represented as a table > > - MERGE / UPSERT > > - Config file "#includes" for postgresql.conf, pg_hba.conf > > - Some better ability to terminate backends > > - Automatically updatable views (per SQL 99) > > Ron Mayer: > Standards stuff: > > * Updateable views (easier to use Ruby/Rails's ActiveRecord on > legacy data) > * The elementary OLAP stuff > > Contrib related stuff: > > * Contrib/xml2 working with XML Namespaces. > * Some sort of GIST index for querying XML data (XPath? > SQL/XML?) > > * The array functions and indexes from contrib/intarray > and contrib/intagg made more general to work with other > data types. (I find these contrib modules quite useful) > > Annoyances: > > * more sane math with intervals. For example, try: > select '0.01 years'::interval, '0.01 months'::interval; > > Ease of use: > > * Nice defaults for autovacuum and checkpoints and bgwriter > that automatically avoid big I/O spikes by magically > distributing I/O in a nice way. > > Easier COPY for client library authors: > > * A way to efficiently insert many values like COPY from STDIN > from client libraries that don't support COPY from STDIN. > Perhaps it could happen through the apparently standards > compliant > "INSERT INTO table VALUES (1,2),(3,4),(5,6)" [feature id > F641] > or perhaps through a new > COPY tablename FROM STRING 'a big string instead of stdin' > feature that would be easier for clients to support? > > It seems in most new client libraries COPY FROM STDIN > stays broken for quite a long time. Would a > alternative COPY FROM A_BIG_STRING be easier for them > to support and therefore available more often? > > Meta-stuff > > * A failover plus load-balancing (pgpool+slony?) > installer for dummies that handles simple cases. > > * A single place to find all the useful non-core stuff > like projects on pgfoundry, gborg, contrib, and > various other places around the net (PL/R PL/Ruby Postgis). > Perhaps if the postgresql website had a small wiki > somewhere where anyone could add links with a short > description to any such projects it'd be easier to > know what's out there... > > * Nice APIs and documentation [probably already exists] > to continue encouraging projects like PostGIS and PL/R > that IMHO are the biggest advantage of postgresql over > the commercial vendors' offerings. > > Heikki Linnakangas: > * concurrent, partial vacuum that would for example only scan > pages that > happen to be in memory > * index-only scans > * database assertions > > * lightwight PITR that wouldn't require to shut down and restore > a backup. > I'm thinking something like "REWIND TO xid 12345". It could be > implemented > by just setting already-committed transactions as aborted in the > clog > (vacuum and commit status hint bits need to be disabled > beforehand). This > would be very handy for automatic regression testing > applications. You > could load the test database just once, then run test case, > rewind, run > another test case, rewind and so on. > > As more disruptive longer-term things: > > * multiple alternative access plans for prepared statements. For > example, > if you have a query like "SELECT * FROM history WHERE timestamp > BETWEEN ? > AND ?", the optimal access plan depends a lot on the parameters. > Postgres > could keep all the plans that are optimal for some combination > of > parameters, and choose the most efficient one at execution time > depending > on the parameters. The execution side would actually be quite > simple to > implement. Introduce a new conditional node type that has > 1 > child > nodes, and a condition that is evaluated at execution time and > determines > which child node to use. Determining the conditions would > require big > changes to the planner and estimation routines. > > * support for Tutorial D as an alternative to SQL. It would be > great for > educational purposes. > > My own wish list: > * Identity/generator support (per standard) > * Merge (update/insert as required) > * Multi-CPU sorts. Take a large single sort like an index > creation and split the work among multiple CPUs. > > -- > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings >
On Sun, Oct 16, 2005 at 01:20:45AM -0700, Kevin McArthur wrote: > Don't forget insert/update returning. With the deprecation of OID's this > functionality is becoming more and more important when using custom types > and column defaults. I use currval/nextval and have never actually needed such a feature, though I can imagine it might be useful. ISTM though this wouldn't be too hard to do. The executor already takes a pointer to the function to send the output rows to. So, fiddle the toplevel plannode to add the returning columns to the output and when it receives the tuple split it into the part to be inserted and the part to be returned. > Some method for plpgsql to handle the result sets returned and save to a > variable would be important for this feature too. Select into works but it > would be silly to see something like select a into somevariable from (insert > into tablename (a) default values returning a) instead of an extension to > the insert statement itself. How do other databases deal with this? Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
On Sun, 2005-16-10 at 01:20 -0700, Kevin McArthur wrote: > Don't forget insert/update returning. Omar Kilani has a patch for this: http://archives.postgresql.org/pgsql-patches/2005-07/msg00568.php I would like to see it get into 8.2 -Neil
Neil Conway wrote: > On Sun, 2005-16-10 at 01:20 -0700, Kevin McArthur wrote: > > Don't forget insert/update returning. > > Omar Kilani has a patch for this: > > http://archives.postgresql.org/pgsql-patches/2005-07/msg00568.php > > I would like to see it get into 8.2 Yes, this is in the 8.2 patches queue: http://momjian.postgresql.org/cgi-bin/pgpatches_hold -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
I fail to see how this solves the problem of getting auto generated keys. AFAIKS, the protocol needs to be tweaked to return at a minimum the currval for the first serial in the row, but more correctly all of the modified currval's for an insert if we had that then we could correctly implement getAutoGeneratedKeys for jdbc. Dave On 17-Oct-05, at 8:33 AM, Bruce Momjian wrote: > Neil Conway wrote: > >> On Sun, 2005-16-10 at 01:20 -0700, Kevin McArthur wrote: >> >>> Don't forget insert/update returning. >>> >> >> Omar Kilani has a patch for this: >> >> http://archives.postgresql.org/pgsql-patches/2005-07/msg00568.php >> >> I would like to see it get into 8.2 >> > > Yes, this is in the 8.2 patches queue: > > http://momjian.postgresql.org/cgi-bin/pgpatches_hold > > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, > Pennsylvania 19073 > > ---------------------------(end of > broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org > >
I've not actually looked in the source but i presume that insert returning would work internally similar to a select in an update_after or insert_after trigger. If so then it should not care that an entry is a sequence or otherwise, it should care what the actual data in the table is. It must work on the actual data to properly work with defaults that are a product of a function that is not a serial. Eg a uniqueidentifier's newid() func. I could be wrong. But insert returning without picking up column defaults would be extremely useless. getAutoGeneratedKeys in jdbc seems like it would be a very useful interface, so if this patch doesnt support implementing this, someone should fix that. (I'd check/fix it myself, but i don't have much of a clue when it comes to c programming) Kevin McArthur ----- Original Message ----- From: "Dave Cramer" <pg@fastcrypt.com> To: "Bruce Momjian" <pgman@candle.pha.pa.us> Cc: "Neil Conway" <neilc@samurai.com>; "PostgreSQL-development" <pgsql-hackers@postgresql.org> Sent: Monday, October 17, 2005 6:12 AM Subject: Re: [HACKERS] PostgreSQL roadmap for 8.2 and beyond. >I fail to see how this solves the problem of getting auto generated keys. > > AFAIKS, the protocol needs to be tweaked to return at a minimum the > currval for the first serial in the row, but more correctly all of the > modified currval's for an insert > > if we had that then we could correctly implement getAutoGeneratedKeys for > jdbc. > > Dave > On 17-Oct-05, at 8:33 AM, Bruce Momjian wrote: > >> Neil Conway wrote: >> >>> On Sun, 2005-16-10 at 01:20 -0700, Kevin McArthur wrote: >>> >>>> Don't forget insert/update returning. >>>> >>> >>> Omar Kilani has a patch for this: >>> >>> http://archives.postgresql.org/pgsql-patches/2005-07/msg00568.php >>> >>> I would like to see it get into 8.2 >>> >> >> Yes, this is in the 8.2 patches queue: >> >> http://momjian.postgresql.org/cgi-bin/pgpatches_hold >> >> >> -- >> Bruce Momjian | http://candle.pha.pa.us >> pgman@candle.pha.pa.us | (610) 359-1001 >> + If your life is a hard drive, | 13 Roberts Road >> + Christ can be your backup. | Newtown Square, Pennsylvania >> 19073 >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 4: Have you searched our list archives? >> >> http://archives.postgresql.org >> >> > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq >
On Mon, Oct 17, 2005 at 09:12:35AM -0400, Dave Cramer wrote:
> I fail to see how this solves the problem of getting auto generated
> keys.
>
> AFAIKS, the protocol needs to be tweaked to return at a minimum the
> currval for the first serial in the row, but more correctly all of
> the modified currval's for an insert
In what sense? It seems to do exactly what you want. The example in the
documentation is:
INSERT INTO films (title) VALUES ('Yojimbo') RETURNING film_id; film_id--------- 123
The protocol allows you to return a result set for any command already
so I don't think there's any protocol changes at all. You don't even
need to know the name of the sequence which is something I wasn't even
hoping for. Well done...
> if we had that then we could correctly implement getAutoGeneratedKeys
> for jdbc.
There is a function now to return the sequence associated with a table
so I think this would be quite straightforward actually, assuming you
know the table being operated on.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Mon, Oct 17, 2005 at 09:12:35AM -0400, Dave Cramer wrote:
>> AFAIKS, the protocol needs to be tweaked to return at a minimum the
>> currval for the first serial in the row, but more correctly all of
>> the modified currval's for an insert
> In what sense? It seems to do exactly what you want. The example in the
> documentation is:
> INSERT INTO films (title) VALUES ('Yojimbo') RETURNING film_id;
What Dave wants is for INSERT to automagically return any autogenerated
keys, *without* any explicit RETURNING clause.
I don't think that's a reasonable request, however: it amounts to a
request to break the protocol and impose possibly-useless overhead on
everyone's inserts, in order to save the JDBC driver some work in
analyzing table metadata.
regards, tom lane
On 17-Oct-05, at 12:43 PM, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
>
>> On Mon, Oct 17, 2005 at 09:12:35AM -0400, Dave Cramer wrote:
>>
>>> AFAIKS, the protocol needs to be tweaked to return at a minimum the
>>> currval for the first serial in the row, but more correctly all of
>>> the modified currval's for an insert
>>>
>
>
>> In what sense? It seems to do exactly what you want. The example
>> in the
>> documentation is:
>>
>
>
>> INSERT INTO films (title) VALUES ('Yojimbo') RETURNING film_id;
>>
>
> What Dave wants is for INSERT to automagically return any
> autogenerated
> keys, *without* any explicit RETURNING clause.
>
Yes, this is the essence of what would be required.
> I don't think that's a reasonable request, however: it amounts to a
> request to break the protocol and impose possibly-useless overhead on
> everyone's inserts, in order to save the JDBC driver some work in
> analyzing table metadata.
The JDBC problem at hand is there is a method which allows one to
retrieve the
autogenerated keys from an insert. I can understand Tom's argument
here. It should
be possible for the driver to build a query from the meta data.
On the other hand given that all of the serial increments are stored
in the session is it possible to
get the results of the last insert on the session ? If we can avoid
the extra query so much
the better, but either way is better than what we have ?
Dave
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that
> your
> message can get through to the mailing list cleanly
>
>
Dave Cramer wrote: > > > On the other hand given that all of the serial increments are stored > in the session is it possible to > get the results of the last insert on the session ? If we can avoid > the extra query so much > the better, but either way is better than what we have ? > > Would that not be the new lastval() function ? cheers andrew
On Mon, Oct 17, 2005 at 01:32:22PM -0400, Dave Cramer wrote: > The JDBC problem at hand is there is a method which allows one to > retrieve the > autogenerated keys from an insert. I can understand Tom's argument > here. It should > be possible for the driver to build a query from the meta data. > > On the other hand given that all of the serial increments are stored > in the session is it possible to > get the results of the last insert on the session ? If we can avoid > the extra query so much > the better, but either way is better than what we have ? ISTM them that the RETURNING patch as given solves your problem nicely. You don't even have to know the name of the sequence, just the name of the primary key column. When you see an INSERT append "RETURNING colname" and you have your answer. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
On 17-Oct-05, at 1:43 PM, Martijn van Oosterhout wrote: > On Mon, Oct 17, 2005 at 01:32:22PM -0400, Dave Cramer wrote: > >> The JDBC problem at hand is there is a method which allows one to >> retrieve the >> autogenerated keys from an insert. I can understand Tom's argument >> here. It should >> be possible for the driver to build a query from the meta data. >> >> On the other hand given that all of the serial increments are stored >> in the session is it possible to >> get the results of the last insert on the session ? If we can avoid >> the extra query so much >> the better, but either way is better than what we have ? >> > > ISTM them that the RETURNING patch as given solves your problem > nicely. > You don't even have to know the name of the sequence, just the name of > the primary key column. When you see an INSERT append "RETURNING > colname" and you have your answer. Well, the driver still needs to know ahead of time which columns are going to be autogenerated. Dave > > Have a nice day, > -- > Martijn van Oosterhout <kleptog@svana.org> http://svana.org/ > kleptog/ > >> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent >> is a >> tool for doing 5% of the work and then sitting around waiting for >> someone >> else to do the other 95% so you can sue them. >
It would be useful if you could toggle SQL statement logging without restarting PostgreSQL and additionally if you could turn on selective SQL logging. Additionally, it would be great if you could log SQL statements to a separate file from the main log and in such a way that the statements are seperated in an easily parsed form. The runtime toggling of statement logging would also be most useful if you could toggle it outside of a particular session. This is where the selective SQL logging would be useful I think. Some selectable options that could be useful:- by database- by user- by IP address My current understanding, is that statements can be currently selectively logged by:- whether they cause an error (log_min_error_statement)- whether they exceed a minimum amount of time (log_min_duration_statement)-ddl and/or data modifications (log_statement) I have no idea on how feasible this is. If it is feasible and nobody else is interested in doing it but it would be accepted if somebody would write it, I would be willing to start investigating how to do it. -----Original Message----- From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of karen hill Sent: Friday, October 14, 2005 9:57 AM To: pgsql-hackers@postgresql.org Subject: [HACKERS] PostgreSQL roadmap for 8.2 and beyond. Autovacuum is getting put into the 8.1 release which is awesome. A lot of us are wondering now that PostgreSQL has all the features that many of us need, what are the features being planned for future releases? What do you see for 8.2 and beyond? What type of features are you devs planning for 9.0? It would be good if you could put up a place on your site so we mortals can drool over up-coming postgresql features. __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
Patrick Bakker <patrick@vanbelle.com> writes:
> It would be useful if you could toggle SQL statement logging without
> restarting PostgreSQL and additionally if you could turn on selective SQL
> logging. Additionally, it would be great if you could log SQL statements to
> a separate file from the main log and in such a way that the statements are
> seperated in an easily parsed form.
> The runtime toggling of statement logging would also be most useful if you
> could toggle it outside of a particular session. This is where the selective
> SQL logging would be useful I think. Some selectable options that could be
> useful:
> - by database
> - by user
> - by IP address
You do realize that the majority of that can be done today? You need to
study the available mechanism for setting GUC parameters a little more.
regards, tom lane
Dave Cramer <pg@fastcrypt.com> writes:
> On 17-Oct-05, at 1:43 PM, Martijn van Oosterhout wrote:
>> ISTM them that the RETURNING patch as given solves your problem
>> nicely.
> Well, the driver still needs to know ahead of time which columns are
> going to be autogenerated.
Possibly you could define that as "all columns that are not specified in
the INSERT command and have column default expressions". The first is
knowable with very little parsing of the command, and the second can be
learned from the catalog metadata that you're probably reading anyway.
If the JDBC spec has a more specific definition of "autogenerated" than
"has a default", then what is it?
regards, tom lane
/me has started working on hierarchical query support that I'd like to get into 8.2.
--
Respectfully,
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
http://www.enterprisedb.com/
On 10/17/05, Tom Lane <tgl@sss.pgh.pa.us > wrote:
Dave Cramer <pg@fastcrypt.com > writes:
> On 17-Oct-05, at 1:43 PM, Martijn van Oosterhout wrote:
>> ISTM them that the RETURNING patch as given solves your problem
>> nicely.
> Well, the driver still needs to know ahead of time which columns are
> going to be autogenerated.
Possibly you could define that as "all columns that are not specified in
the INSERT command and have column default expressions". The first is
knowable with very little parsing of the command, and the second can be
learned from the catalog metadata that you're probably reading anyway.
If the JDBC spec has a more specific definition of "autogenerated" than
"has a default", then what is it?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
--
Respectfully,
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
http://www.enterprisedb.com/
Tom Lane wrote: >Patrick Bakker <patrick@vanbelle.com> writes: > > >>It would be useful if you could toggle SQL statement logging without >>restarting PostgreSQL and additionally if you could turn on selective SQL >>logging. Additionally, it would be great if you could log SQL statements to >>a separate file from the main log and in such a way that the statements are >>seperated in an easily parsed form. >> >> > > > >>The runtime toggling of statement logging would also be most useful if you >>could toggle it outside of a particular session. This is where the selective >>SQL logging would be useful I think. Some selectable options that could be >>useful: >> - by database >> - by user >> - by IP address >> >> > >You do realize that the majority of that can be done today? You need to >study the available mechanism for setting GUC parameters a little more. > > Not quite, if you want to set it on databases you're not connected to, i.e. if you want to 'tap' a backend. Regards, Andreas
> Gavin Sherry: > Grouping sets > Recursive queries The recursive queries is a long-awaited feature. Does the fact that the feature is listed for Gavin Sherry mean that Gavin is actually working with the feature at the moment? Does anybody know the current state of this feature or know when it will be public available?
Hi, On Tue, 14 Nov 2005 rasmusra@gmail.com wrote: > > Gavin Sherry: > > Grouping sets > > Recursive queries > > The recursive queries is a long-awaited feature. Does the fact that the > feature is listed for Gavin Sherry mean that Gavin is actually working > with the feature at the moment? Does anybody know the current state of > this feature or know when it will be public available? I recall suggesting these features as being amongst those in demand. I don't remember saying that I'd actually do them... Gavin
swm@linuxworld.com.au (Gavin Sherry) writes: > Hi, > > On Tue, 14 Nov 2005 rasmusra@gmail.com wrote: > >> > Gavin Sherry: >> > Grouping sets >> > Recursive queries >> >> The recursive queries is a long-awaited feature. Does the fact that >> the feature is listed for Gavin Sherry mean that Gavin is actually >> working with the feature at the moment? Does anybody know the >> current state of this feature or know when it will be public >> available? > > I recall suggesting these features as being amongst those in > demand. I don't remember saying that I'd actually do them... Jonah Harris appears to be working on the Recursive Queries side of it... -- let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;; http://www.ntlug.org/~cbbrowne/sap.html "I visited a company that was doing programming in BASIC in Panama City and I asked them if they resented that the BASIC keywords were in English. The answer was: ``Do you resent that the keywords for control of actions in music are in Italian?''" -- Kent M Pitman
rasmusra@gmail.com wrote: > > Gavin Sherry: > > Grouping sets > > Recursive queries > > The recursive queries is a long-awaited feature. Does the fact that the > feature is listed for Gavin Sherry mean that Gavin is actually working > with the feature at the moment? Does anybody know the current state of > this feature or know when it will be public available? No, it just means he has worked on it in the past. However, I no longer see his name on the item in the current TODO. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Would the PG Dev group be working on update-able views for 8.2 ? I know that there is a work-around using rules, the SAMS book does claim that 8.0 has readonly views. I don't think that this has changed in 8.1 no ? Cheers, Aly. Bruce Momjian wrote: > rasmusra@gmail.com wrote: > >>>Gavin Sherry: >>> Grouping sets >>> Recursive queries >> >>The recursive queries is a long-awaited feature. Does the fact that the >>feature is listed for Gavin Sherry mean that Gavin is actually working >>with the feature at the moment? Does anybody know the current state of >>this feature or know when it will be public available? > > > No, it just means he has worked on it in the past. However, I no longer > see his name on the item in the current TODO. > -- Aly S.P Dharshi aly.dharshi@telus.net "A good speech is like a good dress that's short enough to be interesting and long enough to cover the subject"
Hi all, karen hill wrote: > What do you see for 8.2 and beyond? What type of > features are you devs planning for 9.0? It would be > good if you could put up a place on your site so we > mortals can drool over up-coming postgresql features. I'm wishing - more audit facilities- pluggable/loadable storage manager (and bufmgr?)- in-memory table How do you think? -- NAGAYASU Satoshi <nagayasus@nttdata.co.jp>
Aly Dharshi wrote: > Would the PG Dev group be working on update-able views for 8.2 ? I know that > there is a work-around using rules, the SAMS book does claim that 8.0 has > readonly views. I don't think that this has changed in 8.1 no ? > We don't know what will be in 8.2 until a volunteer does the work. --------------------------------------------------------------------------- > Cheers, > > Aly. > > Bruce Momjian wrote: > > rasmusra@gmail.com wrote: > > > >>>Gavin Sherry: > >>> Grouping sets > >>> Recursive queries > >> > >>The recursive queries is a long-awaited feature. Does the fact that the > >>feature is listed for Gavin Sherry mean that Gavin is actually working > >>with the feature at the moment? Does anybody know the current state of > >>this feature or know when it will be public available? > > > > > > No, it just means he has worked on it in the past. However, I no longer > > see his name on the item in the current TODO. > > > > -- > Aly S.P Dharshi > aly.dharshi@telus.net > > "A good speech is like a good dress > that's short enough to be interesting > and long enough to cover the subject" > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Mon, Nov 14, 2005 at 17:10:58 -0700, Aly Dharshi <aly.dharshi@telus.net> wrote: > Would the PG Dev group be working on update-able views for 8.2 ? I know > that there is a work-around using rules, the SAMS book does claim that 8.0 > has readonly views. I don't think that this has changed in 8.1 no ? It's not really a work around. Updateable views will likely be built on top of rules and just provide a more convenient way to do things for the cases it is clear what updating means.