* Tom Lane (t...@sss.pgh.pa.us) wrote:
After a bit of study of the code, it appears to me that it's not too
difficult to fix: we just have to use the expression's result type
rather than the index column's atttypid in the subsequent processing.
ANALYZE never actually looks at the index column
On fre, 2010-07-30 at 12:50 +0100, Mike Fowler wrote:
* xml_is_well_formed returns true for simple text
postgres=# SELECT xml_is_well_formed('');
xml_is_well_formed
t
(1 row)
it is probably wrong result - is it ok??
Yes this is OK, pure text
On Sat, Jul 31, 2010 at 12:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Another misbehavior that I noted while playing with Artur's example is
that, while GIN index build seems to adhere pretty well to whatever
maintenance_work_mem limit you give it in 8.4, it blows right by that
limit in 9.0 and
I fixed the problem I was on about earlier with ginget.c doing the wrong
thing for keystreams like this:
... ...
42/642/65535
42/7...
...
(To recap, after reporting the potential lossy match for 42/6, the
previous code would
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
After a bit of study of the code, it appears to me that it's not too
difficult to fix: we just have to use the expression's result type
rather than the index column's atttypid in the subsequent processing.
ANALYZE
On Jul 31, 2010, at 11:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It's only been very recently that we had any useful stats capability
that could apply in such situations (in fact I think we still haven't
actually shipped a non-bogus version of tsvector typanalyze :-().
So I'm not sure anyone
Robert Haas robertmh...@gmail.com writes:
On Sat, Jul 31, 2010 at 12:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So, I would like somebody to show cause why that whole module shouldn't
be ripped out and the code reverted to where it was in 8.4. My
recollection is that the argument for adding it
On Fri, Jul 30, 2010 at 4:38 PM, Yeb Havinga yebhavi...@gmail.com wrote:
I'm looking at ATPrepAddColumn right now, where there is actually some
comments about getting the right attinhcount in the case of multiple
inherited children, but it's the first time I'm looking at this part of
Robert Haas robertmh...@gmail.com writes:
I think this whole discussion is starting with the wrong premise. This
is not a bug fix; therefore, it's 9.1 material.
Failing to store stats isn't a bug?
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Sat, Jul 31, 2010 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Jul 31, 2010 at 12:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So, I would like somebody to show cause why that whole module shouldn't
be ripped out and the code reverted to
Robert Haas robertmh...@gmail.com writes:
On Sat, Jul 31, 2010 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm tempted to suggest that making RBNode be a hidden struct containing
a pointer to somebody else's datum is fundamentally the wrong way to
go about things, because the extra void
On Sat, Jul 31, 2010 at 12:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Jul 31, 2010 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm tempted to suggest that making RBNode be a hidden struct containing
a pointer to somebody else's datum is
Robert Haas robertmh...@gmail.com writes:
On Sat, Jul 31, 2010 at 12:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
So it'd definitely be a lot better than now. Maybe there'd be some
remaining performance gap for non-pathological cases, but I think we
would be willing to pay that in order to avoid
On Sat, Jul 31, 2010 at 12:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think this whole discussion is starting with the wrong premise. This
is not a bug fix; therefore, it's 9.1 material.
Failing to store stats isn't a bug?
Well, it kind of sounds
On Sat, Jul 31, 2010 at 8:10 AM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2010-07-30 at 12:50 +0100, Mike Fowler wrote:
* xml_is_well_formed returns true for simple text
postgres=# SELECT xml_is_well_formed('');
xml_is_well_formed
t
(1 row)
it
Robert Haas 07/31/10 12:33 PM
Tom Lane wrote:
Robert Haas writes:
I think this whole discussion is starting with the wrong premise.
This is not a bug fix; therefore, it's 9.1 material.
Failing to store stats isn't a bug?
Well, it kind of sounds more like you're removing a known
On Thu, Jul 29, 2010 at 7:56 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
The patch is in context diff format and applies cleanly. No doc
changes were included. Arguably there should be a mention in the
documentation for psql's \d+ commend, but since the number of child
tables and
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
Robert Haas 07/31/10 12:33 PM
Tom Lane wrote:
Failing to store stats isn't a bug?
Well, it kind of sounds more like you're removing a known
limitation than fixing a bug.
It's operating as designed and documented. There is
Excerpts from Tom Lane's message of sáb jul 31 09:57:13 -0400 2010:
So far as I can see, it's impossible to handle this situation when
examining only one TID per stream with no lookahead. Choosing to
advance the second stream would obviously fail in many other cases,
so there is no correct
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of sáb jul 31 09:57:13 -0400 2010:
So far as I can see, it's impossible to handle this situation when
examining only one TID per stream with no lookahead. Choosing to
advance the second stream would obviously
On Sat, Jul 31, 2010 at 9:16 PM, Stephen Frost sfr...@snowman.net wrote:
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
Robert Haas 07/31/10 12:33 PM
Tom Lane wrote:
Failing to store stats isn't a bug?
Well, it kind of sounds more like you're removing a known
limitation than
On Sun, Jul 25, 2010 at 11:42 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
I'm setting this as ready for committer.
Thank you very much
I took a look at this tonight and am a bit mystified by the following bit:
+ /*
+* PL doesn't calculate
Robert Haas robertmh...@gmail.com writes:
On Sat, Jul 31, 2010 at 12:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
So it'd definitely be a lot better than now. Maybe there'd be some
remaining performance gap for non-pathological cases, but I think we
would be willing to pay that in order to avoid
Robert Haas robertmh...@gmail.com writes:
I took a look at this tonight and am a bit mystified by the following bit:
+ /*
+* PL doesn't calculate first row of function's body
+* when first row is empty. So checks first row,
Robert Haas robertmh...@gmail.com writes:
On Sat, Jul 31, 2010 at 9:16 PM, Stephen Frost sfr...@snowman.net wrote:
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
Robert Haas 07/31/10 12:33 PM
Tom Lane wrote:
Failing to store stats isn't a bug?
Well, it kind of sounds more like
2010/8/1 Robert Haas robertmh...@gmail.com:
On Sun, Jul 25, 2010 at 11:42 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I'm setting this as ready for committer.
Thank you very much
I took a look at this tonight and am a bit mystified by the following bit:
+ /*
+
2010/7/31 Greg Smith g...@2ndquadrant.com
Boxuan Zhai wrote:
I create a clean patch file (no debug clauses). See the attachment.
Some general coding feedback for you on this.
Thanks for your consideration!
It's not obvious to people who might want to try this out what exactly they
are
27 matches
Mail list logo
