On Sun, Jun 14, 2009 at 1:15 AM, Pavel Stehule wrote:
> can somebody explain this behave?
>
> postgres=# select '10' ~ e'^\\d+$';
> ?column?
> --
> t
> (1 row)
> ok
>
> postgres=# select '10' ~ '[0..9]+$';
> ?column?
> --
> t
> (1 row)
> ok
>
> postgres=# select '10' ~ '^[0..9]+
Hello
can somebody explain this behave?
postgres=# select '10' ~ e'^\\d+$';
?column?
--
t
(1 row)
ok
postgres=# select '10' ~ '[0..9]+$';
?column?
--
t
(1 row)
ok
postgres=# select '10' ~ '^[0..9]+$';
?column?
--
f
(1 row)
?
postgres=# select version();
On Sunday 14 June 2009 07:27:19 Robert Haas wrote:
> On Sat, Jun 13, 2009 at 7:42 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> In any event, considering that EXPLAIN is a utility statement and
> >> can't be embedded within a query, I'm not sure what benefit we get out
> >> of returning the dat
On Saturday 13 June 2009 22:01:43 Robert Haas wrote:
> > I recommend, however, that you think about writing a regression test for
> > this, so the interfaces are explicit, and those tweaking them in the
> > future know what they are dealing with.
>
> I would like to have something in this area, but
On Saturday 13 June 2009 22:01:43 Robert Haas wrote:
> > * Instead of , use with an XML namespace
> > declaration.
>
> Could you specify this a bit further, like write out exactly what you
> want it to look like? My XML-fu is not very strong.
Just replace your by
http://www.postgresql.org/2009
On Sat, Jun 13, 2009 at 7:42 PM, Tom Lane wrote:
> Robert Haas writes:
>> In any event, considering that EXPLAIN is a utility statement and
>> can't be embedded within a query, I'm not sure what benefit we get out
>> of returning the data as XML rather than text. This doesn't seem
>> likely to ch
Robert Haas writes:
> In any event, considering that EXPLAIN is a utility statement and
> can't be embedded within a query, I'm not sure what benefit we get out
> of returning the data as XML rather than text. This doesn't seem
> likely to change either, based on Tom's comments here.
> http://ar
On Sat, Jun 13, 2009 at 6:40 PM, Tom Lane wrote:
> Bernd Helmle writes:
>> --On 13. Juni 2009 15:01:43 -0400 Robert Haas wrote:
Also, the result type of an EXPLAIN (format xml) should be type xml, not
text.
>>>
>>> Seems reasonable. I'll see if I can figure out how to do that.
>
>> I s
Bernd Helmle writes:
> --On 13. Juni 2009 15:01:43 -0400 Robert Haas wrote:
>>> Also, the result type of an EXPLAIN (format xml) should be type xml, not
>>> text.
>>
>> Seems reasonable. I'll see if I can figure out how to do that.
> I suppose it's okay then, that the format is not available w
--On 13. Juni 2009 15:01:43 -0400 Robert Haas wrote:
Also, the result type of an EXPLAIN (format xml) should be type xml, not
text.
Seems reasonable. I'll see if I can figure out how to do that.
I suppose it's okay then, that the format is not available when the server
isn't build with
On Sat, Jun 13, 2009 at 2:48 PM, Tom Lane wrote:
> Greg Stark writes:
>> I'm not sure about that. It seems like race conditions with autovacuum
>> are a real potential bug that it would be nice to be testing for.
>
> It's not a bug; it's a limitation of our testing framework that it sees
> this as
On Sat, Jun 13, 2009 at 9:08 AM, Peter Eisentraut wrote:
> On Saturday 13 June 2009 01:10:06 Robert Haas wrote:
>> , as it happens... I could post some samples of the
>> output, but it seems like it might be just as well to let those who
>> are curious try it for themselves. I'd rather get opinio
Greg Stark writes:
> I'm not sure about that. It seems like race conditions with autovacuum
> are a real potential bug that it would be nice to be testing for.
It's not a bug; it's a limitation of our testing framework that it sees
this as a failure. Serious testing for autovac race conditions
Sorry for top-posting -- stupid apple mail client...
I'm not sure about that. It seems like race conditions with autovacuum
are a real potential bug that it would be nice to be testing for.
Another solution would be adding an order by clause - effectively
trading coverage of unordered raw s
Every so often the buildfarm shows row-ordering differences in the copy2
test, for example
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=jaguar&dt=2009-06-13%2003:00:02
("jaguar" seems particularly prone to this for some reason, but other
members have shown it too.) I believe what is happening
2009/6/7 Tom Lane :
> So there are a lot of good reasons to work backwards in patching.
> I don't believe that these would be outweighed by some advantage
> in the mechanics of applying an unchanging patch to multiple
> branches (especially since AFAICT the mechanical advantage would
> be pretty da
Robert Haas writes:
> This errdetail doesn't seem quite right in the following situation:
> rhaas=# select distinct proacl from pg_proc;
> ERROR: could not implement DISTINCT
> DETAIL: Some of the datatypes only support hashing, while others only
> support sorting.
Hmm, interesting case. The r
Andrew Dunstan writes:
> Peter Eisentraut wrote:
>> On Wednesday 10 June 2009 23:54:41 Tom Lane wrote:
>>> At a quick look, I'm not sure that any of these are in code that hasn't
>>> been edited since the 8.3 pgindent run.
>>
>> So what does that mean then? Surely pgindent doesn't keep track of
Peter Eisentraut wrote:
On Wednesday 10 June 2009 23:54:41 Tom Lane wrote:
Peter Eisentraut writes:
I think it usually does that already ...
Um, attached you will find a bunch of counterexamples.
At a quick look, I'm not sure that any of these are in code that has
On Wednesday 10 June 2009 23:54:41 Tom Lane wrote:
> Peter Eisentraut writes:
> >>> I think it usually does that already ...
> >
> > Um, attached you will find a bunch of counterexamples.
>
> At a quick look, I'm not sure that any of these are in code that hasn't
> been edited since the 8.3 pginde
On Saturday 13 June 2009 01:10:06 Robert Haas wrote:
> , as it happens... I could post some samples of the
> output, but it seems like it might be just as well to let those who
> are curious try it for themselves. I'd rather get opinions from
> people who care enough to download & test than from
I'm currently doing some benchmarking on a Nehalem
box(http://www.kaltenbrunner.cc/blog/index.php?/archives/26-Benchmarking-8.4-Chapter-1Read-Only-workloads.html)
with 8.4 and while investigating what looks like issues in pgbench I
also noticed that using char() has more than a negligable overhe
On Sun, Jun 07, 2009 at 12:29:56AM -0400, Tom Lane wrote:
> David Fetter writes:
> > Would it be super-complicated to do this with CTEs for 8.5? They
> > seem to have sane properties like getting executed exactly once.
>
> Hmm, interesting thought. The knock against doing RETURNING as an
> ordi
Le 12 juin 09 à 23:20, Tom Lane a écrit :
Dimitri Fontaine writes:
Le 12 juin 09 à 21:49, Tom Lane a écrit :
It seems to me it could still do
with a lot more detail to specify what API the functions are really
expected to implement.
What's bothering me is the fuzziness of the API
specificati
24 matches
Mail list logo
