Martijn van Oosterhout wrote:
On Thu, Sep 27, 2007 at 02:48:52PM +0530, Anoo Sivadasan Pillai wrote:
Description : I have two tables with the same data , While I issue an
update command to increment the value of a unique field by 1, the
statement fails in one table and will succeed in the
Stephen Frost wrote:
* Dave Page ([EMAIL PROTECTED]) wrote:
/* We only show the rel name, not schema name */
relname = get_rel_name(rte-relid);
Anyone know why? This seems like a bug to me given the ambiguity of
possible output.
I'd assume it's to keep the explain output smaller with the
Tom Lane wrote:
I agree with the idea of having an option to get EXPLAIN's output in
an entirely different, more machine-readable format. Not wedded to
XML, but I fear that a pure relational structure might be too strict ---
there's a lot of variability in the entries already. XML also could
Gregory Stark wrote:
Billings, John [EMAIL PROTECTED] writes:
Does anyone think that PostgreSQL could benefit from using the video
card as a parallel computing device? I'm working on a project using
Nvidia's CUDA with an 8800 series video card to handle non-graphical
algorithms. I'm curious
Neil Conway wrote:
Clearly, the current approach is fine when the array is small -- perhaps
for arrays above a certain number of elements, we could switch to
randomly sampling array elements, estimating their selectivities, and
then using that information to infer the estimated selectivity of
Abraham, Danny wrote:
Hi,
I am migrating from Sybase to Postgres.
trying to get a hold on the issue of future releases feature list.
1. Where can I find the feature list for 8.3 ? When is it expected?
2. And for 8.4?
There are various places to look for this kind of information, but
Jim Nasby wrote:
On May 8, 2007, at 9:50 AM, Andrew Sullivan wrote:
On Mon, May 07, 2007 at 07:36:55AM -0500, Jim Nasby wrote:
Instead, if all feature requests are tracked then users can vote on
what's most important to them.
I am sympathetic to the issues you and Andrew are describing (I
Hi,
guess I missed hackers on my initial reply. So I am re-sending the reply
I send to Joshua based on the reply I send to him in regards to a
hackers@ posting.
Read below.
regards,
Lukas
Joshua D. Drake wrote:
That being said, it seems obvious that so far PostgreSQL has been
mainly
Tom Lane wrote:
The first design that comes to mind is that at transaction end
(pgstat_report_tabstat() time) we send a stats message only if at least
X milliseconds have elapsed since we last sent one, where X is
PGSTAT_STAT_INTERVAL or closely related to it. We also make sure to
flush stats
Alvaro Herrera wrote:
Yeah; the agreement we had was that 8.3 would be a short release. So if
we're going to take too long to review and apply the outstanding patches
we have, we should rather push them to 8.4, get 8.3 released quickly and
then go on with the regular annual release. The
Stefan Kaltenbrunner wrote:
2) Introduce a new patch management system. I suggest a web interface
through which patches be submitted. This would assign them an ID number,
and forward them to the patches list. The system would track any
responses to the initial email, logging the thread
Hello,
Currently on the wishlist [1] we have the following items as posponed:
* WITH RECURSIVE hierarchical queries (Gregory Stark)
* SQL:2003 windowing queries (Gavin)
* Fix permissions properly on custom GUC vars (Andrew Dunstan)
* Create a mechanism for plperl to load modules safely (Andrew
Andrew Dunstan wrote:
Tom Lane wrote:
Even more to the point, getting paid for has almost nothing to do
with has commit privileges. At least on this project.
Darn. So the cheque isn't really in the mail?
I think his question was just which ratio of developers works on
PostgreSQL on
Andrew Dunstan wrote:
Chad Wagner wrote:
There is some point in putting it in a wiki where we can gather
relevant
documents, links to discussions etc. That's why the developers'
wiki was
established, AIUI.
To be honest, it may be adequate to maintain this solely through
Simon Riggs wrote:
If this is standards-breaking as you say, I would withdraw immediately.
I checked the SQL standard and could not see how this would do so. The
standard states SELECT * would return columns in order; it doesn't say
what that order should be, nor does CREATE TABLE enforce the
Bruce Momjian wrote:
Lukas Kahwe Smith wrote:
Simon Riggs wrote:
If this is standards-breaking as you say, I would withdraw immediately.
I checked the SQL standard and could not see how this would do so. The
standard states SELECT * would return columns in order; it doesn't say
what
Joshua D. Drake wrote:
Hello,
5 weeks to feature freeze folks. Please provide updates including if you
think you will have a patch submitted before feature freeze. Be
realistic, if you can't make it -- say so.
Alvaro Herrera: Autovacuum improvements (maintenance window etc..)
Gavin Sherry:
Hey,
Anyone who followed the thread willing to list the mentioned
requirements as well as the pro's and con's of the differnent options in
the developer wiki [1]? I think this would help a lot in making a
decision and it could be a lot of help for other OSS projects
considering to switch.
Hannu Krosing wrote:
Ühel kenal päeval, L, 2007-02-17 kell 13:35, kirjutas Lukas Kahwe Smith:
Lukas Kahwe Smith wrote:
I just wanted to bring up the wishlist todo items:
http://developer.postgresql.org/index.php/Todo:WishlistFor83
What does/did the row Clustered/replication solutions refer
Tom Lane wrote:
Lukas Kahwe Smith [EMAIL PROTECTED] writes:
I remember that there was discussion about invalidating plans who's
estimated cost turn out to be severely off when executed.
That's something we might think about after the infrastructure is in
place. But the question to answer
Tom Lane wrote:
place. But the question to answer is why the re-plan won't yield
just the same plan as before.
oh and when the estimated cost repeatedly do not match the actual cost,
we of course want to generate an email with all relevant information
that is send to this list ;)
Lukas Kahwe Smith wrote:
I just wanted to bring up the wishlist todo items:
http://developer.postgresql.org/index.php/Todo:WishlistFor83
I have gotten feedback from most items on the list and I have updated
the list accordingly. Maybe a few of the items can even be moved to
Completed
Tom Lane wrote:
Relcache inval casts a fairly wide net; for example, adding or dropping an
index will invalidate all plans using the index's table whether or not
they used that particular index, and I believe that VACUUM will also
result in a relcache inval due to updating the table's pg_class
Hi,
I know this is slightly off topic, but I hope still useful enough to not
get my head cut off for posting this:
http://developer.postgresql.org/index.php/IRC2RWNames
This is essentially a mapping of IRC nicks to real world names. While
maintaining the wishlist I keep forgetting the IRC
Bruce Momjian wrote:
Lukas Kahwe Smith wrote:
Hi,
I know this is slightly off topic, but I hope still useful enough to not
get my head cut off for posting this:
http://developer.postgresql.org/index.php/IRC2RWNames
This is essentially a mapping of IRC nicks to real world names. While
Aloha,
I just wanted to bring up the wishlist todo items:
http://developer.postgresql.org/index.php/Todo:WishlistFor83
All items have a name behind them aside from Better handling of
partitioning. Does anyone feel responsible for handling that one?
Anyways I would appreciate it if people
Pavel Stehule wrote:
Postponed
The following features are unlikely to make it into 8.3 at this point:
* SQL/PSM support per SQL:2003 (Pavel)
* Clustered/replication solutions
SQL/PSM is available (without resignal stmt and extended diagnostic
stmt). Some people work on doc translation
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Surely, I've created one (nickname: Nikolay) and are
trying to do things being logged in :-)
You should be able to edit now with the Nikolay account.
If anyone else is having problems, please send me an email.
I'll
Joshua D. Drake wrote:
Lukas Kahwe Smith wrote:
Joshua D. Drake wrote:
Great! I will put it on my, Remember to bug Arul list :)
Hey Joshua,
could you put this stuff here:
http://developer.postgresql.org/index.php/Todo:WishlistFor83
Sure if you bother to unlock the page for me ;)
hmm
Joshua D. Drake wrote:
Great! I will put it on my, Remember to bug Arul list :)
Hey Joshua,
could you put this stuff here:
http://developer.postgresql.org/index.php/Todo:WishlistFor83
I will try to find some time during this week (likely on the weekend) to
also try and figure out if these
Andrew Dunstan wrote:
The latter does not exist, AFAIK. Before feature freeze for cycle X, we
don't usually hold patches for release X+1, as I understand it.
In general, we should try to hold patches as little amount of time as
possible. That way they don't go stale as easily.
I did not
Alvaro Herrera wrote:
news.postgresql.org wrote:
While we are on the topic, I have implemented a poor mans nested
transaction feature into my database access layer. essentially
subsequent calls to begin a transaction after the initial begin simply
increase an internal counter and set a
Tom Lane wrote:
Lukas Kahwe Smith [EMAIL PROTECTED] writes:
Err, I think you misunderstood what I said. My implementation uses
SAVEPOINTs already. The point is having some API where you do not have
to care of you are already in a transaction or not.
It's not that hard
Bruce Momjian wrote:
[1] http://developer.postgresql.org/index.php/Todo:WishlistFor83
That looks helpful.
Ok good :)
Seriously though, please slap me when things are wrong, not assigned yet
to the correct person .. there was a bit of guess work involved with
some of the points ..
Hi,
I just collected all the items mentioned in this thread as well as what
people quickly came up with on IRC and put it on a list in the developer
wiki [1]. I tried to put names and links behind the items where ever
possible. Let me know if there is something missing or if you know any
Hi,
I think another point you need to bring out more clearily is that the
community is also often miffed if they feel they have been left out of
the design and testing phases. This is sometimes just a reflex that is
not always based on technical reasoning. Its just that as you correctly
Joshua D. Drake wrote:
O.k. in all Bruce I like your article but I must admit it seems to take
a The community is god perspective and that we must all bend to the
will of said community.
The community could learn a great deal from adopting some of the more
common business practices when it
Hi,
PostgreSQL 8.2 is out of the door. Unfortunately the plans for a more
detailed todo list have not come into reality yet to assist in for the
next 8.3 release. A couple people have replied to my earlier request to
form a little team willing to work on this, but unfortunately people
seem
Martijn van Oosterhout wrote:
By following your suggestion we would get the following oddity:
SELECT NULL = '', NULL || 'fisk' = '' || 'fisk';
We would return NULL for the first and true for the second. Surely
that's not logical?
The problem is really that Oracle does not differntiate
Andreas Joseph Krogh wrote:
If aggregates ignore NULL one could argue that so shuld the ||-operator?
I agree that this behaviour may seem pedantic, but changing this is only
going to lead to a huge wtf? factor. The baviour for NULL in aggregates
is pretty well documented and known. Even
Mario Weilguni wrote:
Nice, but I still prefer nvl. Coalesce is hard to pronounce, and even harder to
type.
amen .. coalesce was invented by a sadistic twit (something which people
have also called me .. so it goes).
regards,
Lukas
---(end of
Neil Conway wrote:
I think a more sensible proposal could be made for some sort of optional
compatibility mode, as has been discussed many times in the past:
different NULL handling could theoretically be part of an Oracle SQL
dialect.
even more exciting in this context would be to add user
Lukas Kahwe Smith wrote:
Peter Eisentraut wrote:
Am Montag, 18. September 2006 09:20 schrieb Lukas Kahwe Smith:
This just reminds me, are there plans to take into account multibyte
server encodings inside the client quote function?
Huh?
Ah, I just checked the libpq docs and there seems
Dave Page wrote:
I have now moved the wiki installation to:
http://developer.postgresql.org/
BTW: I am wondering if there is an RSS feed of the changes?
On my wiki I have an RSS feed for every page, subwiki (aka area) and the
entire wiki people can subscribe to:
Martijn van Oosterhout wrote:
On Mon, Sep 18, 2006 at 03:49:29PM +0200, Lukas Kahwe Smith wrote:
I agree pretty much. However I disagree that a wiki is not useful to
summarize discussion from the mailinglist. All that it needs is people
that are humble and do not push their own agendas
Tom Lane wrote:
I see the following items standing between us and putting out 8.2beta1:
* Set client encoding based on OS environment - Peter E.
I'm not sure whether Peter is intending to complete this item for 8.2
or not, but if it's to be done it ought to be done before we start beta.
This
Peter Eisentraut wrote:
Am Montag, 18. September 2006 09:20 schrieb Lukas Kahwe Smith:
This just reminds me, are there plans to take into account multibyte
server encodings inside the client quote function?
Huh?
Ah, I just checked the libpq docs and there seems to be a
PQescapeStringConn
Andrew Dunstan wrote:
Being slightly more abstract, we are grappling with a couple of
different kinds of objects here: discussions and decisions. The mailing
list is a very good way of having a discussion, and a wiki is IMNSHO a
poor substitute. Ditto, bulletin board, web forum, blog .
Andrew Dunstan wrote:
Well, of course, the internet is renowned for its preponderance of
people overburdened with humility and fairness. :-)
I think if you ask the php development team the chances are high that
they will agree that I have done exactly that for the PHP todo list.
Seriously,
Joshua D. Drake wrote:
Gregory Stark wrote:
Josh Berkus josh@agliodbs.com writes:
I was actually hoping for more feedback on the content itself. I'm
still not clear if it's supposed to be developers only - to the
exclusion of users or developers only - but accessable to anyone.
It should be
Stefan Kaltenbrunner wrote:
Interesting idea but we already have one of the fastest release cycles
of all database systems and some people would like to see a larger cycle.
I think the key complaint is about how painful the upgrade process is
and if you still get fixes for previous releases
Tom Lane wrote:
AFAICS the bottom line here is that we need some intelligent filtering.
In the short run I doubt that we can have that except through human
gruntwork to filter the mail traffic and update a tracker database.
Maybe after we see such a system in operation for awhile, we can start
Andrew Dunstan wrote:
I spent months on a working party on these and similar issues a few
years back, in a commercial setting. One of the big issues is when you
start tracking something. Bugs are a pretty simple case. Features are
much harder to handle. Someone comes up with an idea. There is
Andrew Dunstan wrote:
It would make the process more transparent, which is something several
people have expressed a desire for.
Yes, the processes seems to work by having two of the most important
people waste time on getting information anyone else could collect, or
that the developer
Lukas Kahwe Smith wrote:
For example I have no expertise in coding on Postgres, but I think I
would be able to collect information from this mailinglist (like specs,
url's etc.) and put them in some issue tracker or wiki. I have done
exactly the same for PHP [1] (though there are rarely specs
Robert Treat wrote:
No offense, a whole lot of this thread seems to be positioned that way, but
the real problem seems to be we do not have enough patch reviewers. ISTM the
questions we should be asking are who can actually help out with patch review
and then ask those people why they
Peter Eisentraut wrote:
Martijn van Oosterhout wrote:
I remember something about setting up a wiki for a todo list and pie
in the sky list. I thought it had promise, but until the wiki is
there we won't know...
I think the wiki is the prerequisite for many ideas about alternative
tracking
Greg Sabino Mullane wrote:
Yes, maintaining it will be a royal pain in the butt. But my theory has
been if you build it, they will come. It will require a lot of human
interaction, as automation only takes you so far, especially when trying
to parse mailing list messages. But if we eventually
Joshua D. Drake wrote:
That wiki is wrong. :) It was set up wrong and configured wrong. It was
supposed to be for developers only.
There is also another wiki that is a trac based that was set up at dave
pages request (for slaves_to_www).
Setup something better, until then we can start
Bruce Momjian wrote:
Lukas Kahwe Smith wrote:
Robert Treat wrote:
No offense, a whole lot of this thread seems to be positioned that way, but
the real problem seems to be we do not have enough patch reviewers. ISTM the
questions we should be asking are who can actually help out with patch
Bruce Momjian wrote:
It seems that you have been the only busy bee so far, and we definitely
need more for this to work.
Yea, I was afraid that was the answer. :-(
But we have a few volunteers, like me for example.
Now don't say I was afraid that was the answer again or I might feel
Martijn van Oosterhout wrote:
On Thu, Aug 31, 2006 at 07:04:07PM -0400, Gregory Stark wrote:
The server has to prepare the query sometime. The v3 protocol just gives you
control over when that happens, but it doesn't force you to do it at any
particular time.
Not really. All named prepares
Peter Eisentraut wrote:
Am Donnerstag, 31. August 2006 14:52 schrieb Csaba Nagy:
So for the like query case you could save 2 plans, one for the indexable
case, one for the not indexable case. Then at runtime you choose the
proper one based on the pattern value.
OK, why don't you work out an
Martijn van Oosterhout wrote:
On Thu, Aug 31, 2006 at 11:27:18AM -0400, Tom Lane wrote:
I'd wish that we reconsider when and how prepared statements are used. The
JDBC interface and PL/pgSQL are frequently noticed perpetrators, but the
problem is really all over the place.
AFAIK those are
Lukas Kahwe Smith wrote:
Martijn van Oosterhout wrote:
On Thu, Aug 31, 2006 at 11:27:18AM -0400, Tom Lane wrote:
I'd wish that we reconsider when and how prepared statements are
used. The JDBC interface and PL/pgSQL are frequently noticed
perpetrators, but the problem is really all over
Markus Schiltknecht wrote:
Marc G. Fournier wrote:
Fixed, sorry for delay ...
Good, thank you. But I've already switched back to IMAP, with subfolders
and automatic filtering. Has the advantage of being available from any
IMAP capable client _and_ saving the flags.
Looks like the news
Reinoud van Leeuwen wrote:
On Thu, Aug 10, 2006 at 09:02:36PM -0700, Joshua D. Drake wrote:
I think it is a combination of the two. A wiki could be used to discuss
ideas for todos, it could be used to describe TODOs in actual detail, it
could used (in conjunction with Trac) to be able to
Bruce Momjian wrote:
I am saying other people can try a new system, but I don't have time to
try something different when no evidence has been given that it is
better (just different).
Ok, not sure if I am in a position to call shots like I am about to,
but here it goes:
Could everybody who
Marc G. Fournier wrote:
But, that isn't our role ... that should be the role of whomever takes
on the role of 'maintainer' for such a monolithic distribution ... its
no more our role to decide that pl/Java is better or worse then pl/J ...
our role is to provide that core for everyone else to
Marc G. Fournier wrote:
Yeah, but if PostgreSQL decides to endorse one monolithic distro in
the way I described it could give that project hopefully the necessary
lift. And the ultimate goal is obviously that some of those newbies
coming by way of the monolithic distro turn into people that
Martijn van Oosterhout wrote:
On Sat, May 20, 2006 at 10:36:25AM +0200, Lukas Smith wrote:
The improvements to the installer are great, but there simply needs to
be a packaged solution that adds more of the things people are very
likely to use. From my understanding Bizgres goes in that
David Fetter wrote:
On Thu, May 18, 2006 at 09:58:21PM +0200, Lukas Smith wrote:
In what way is this outdated? Please provide a specific example.
see below ..
You have to understand that MySQL evolves just like PostgreSQL does.
If it were true, I would have to understand it, but the
Bruce Momjian wrote:
Right, if the cardinality changes, you realize this before execution and
optimize/save the plan again. A further optimization would be to save
_multiple_ plans for a single prepared plan based on constants and
choose one of the other, but that is beyond where we are
73 matches
Mail list logo
