Josh Berkus writes:
> Hmmm, this is a common enough case that it ought to be documented
> somewhere though.How about if I add an example to F.31.2. Converting
> a pre-8.3 Installation ?
I think it already points out the need to manually convert your
configuration, but feel free to fill in s
No, we should not. It's up to the user to create a "default" config
that matches whatever they were using before.
Oh, good point. I was assuming that "Default" would match the user's
default, but of course it might not.
Hmmm, this is a common enough case that it ought to be documented
so
Josh Berkus writes:
> The Tsearch2.sql compatibility fuctions in
> /contrib/tsearch2/tsearch2.sql don't include an important compatibility
> object. For 8.2 Tsearch2 usage, a lot of queries were written calling
> the "default" config, like:
> to_tsvector('default',somedata)
> In 8.3 this fai
We still have a little work to do on dependencies in parallel
pg_restore. The current test compares the candidate's locking
dependencies with those of the running jobs, and allows the candidate is
there isn't a match. That's not a broad enough test. The candidate will
block if there's a curre
Hi,
On Thu, Apr 9, 2009 at 9:47 PM, Heikki Linnakangas
wrote:
>> + if (strspn(buf, "smart") == 5 && strncmp(buf, "smart", 5) == 0)
>> + {
>
> The strspn() call seems pointless here.
OK, I'll get rid of it.
>
> One problem with this patch is that in smart mode, the trigger file is no
On Thu, Apr 9, 2009 at 11:14 PM, Bruce Momjian wrote:
> Done with attached patch; good idea.
Bruce,
You are a documentation-tuning machine... thanks.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
Robert Haas wrote:
> On Sat, Apr 4, 2009 at 6:08 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> http://developer.postgresql.org/pgdocs/postgres/monitoring-stats.html
> >> says: "Note: blocks_fetched minus blocks_hit gives the number of
> >> kernel read() calls issued for the table, index, or da
All,
The Tsearch2.sql compatibility fuctions in
/contrib/tsearch2/tsearch2.sql don't include an important compatibility
object. For 8.2 Tsearch2 usage, a lot of queries were written calling
the "default" config, like:
to_tsvector('default',somedata)
In 8.3 this fails with a "No such config
Tom Lane wrote:
> Robert Haas writes:
> > http://developer.postgresql.org/pgdocs/postgres/monitoring-stats.html
> > says: "Note: blocks_fetched minus blocks_hit gives the number of
> > kernel read() calls issued for the table, index, or database; but the
> > actual number of physical reads is usua
I wrote:
> Tom Lane wrote:
>> I think you are confusing parsing of the string literal that
>> is the argument of CREATE FUNCTION with the parsing that the
plpgsql
>> interpreter does on the function body once it gets it.
> Oh, I'm not confused about that at all. I'm arguing that it's a bad
>
Teodor Sigaev writes:
>> We have an API definition by which extractQuery can distinguish "all
>> match" from "no match". If we just legislate that "some match" isn't
>> a valid behavior for zero-key queries, then the code is correct and the
> Right now I don't see an example with zero keys and "
Tom Lane wrote:
> I think you are confusing parsing of the string literal that
> is the argument of CREATE FUNCTION with the parsing that the plpgsql
> interpreter does on the function body once it gets it. In
> particular, this example:
>
> create or replace function kjgtest() returns text lan
"Kevin Grittner" writes:
> Unless I'm missing something, plpgsql *already* effectively recognizes
> and respects the standard_conforming_strings GUC *except* as the last
> character of a conforming string literal within the procedure body,
> and then not always. Am I missing something here?
Yes -
On 04/08/09 13:10, Josh Berkus wrote:
On 4/8/09 9:44 AM, Tom Lane wrote:
Josh Berkus writes:
What about seq scans?
If the kernel can't read-ahead a seqscan by itself, it's unlikely to
be smart enough to be helped by posix_fadvise ... or at least so I
would think. Do you have reason to thi
"Kevin Grittner" wrote:
> Well, surely the 8.3 behavior is not what we want.
Unless I'm missing something, plpgsql *already* effectively recognizes
and respects the standard_conforming_strings GUC *except* as the last
character of a conforming string literal within the procedure body,
and then
On 4/9/09 10:42 AM, Bruce Momjian wrote:
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
Peter Eisentraut writes:
Here is my thinking, and considering that that would basically involve a
forward-looking design decision right now, I would support dropping the
cardinality() function fr
Andrew Gierth wrote:
> > "Bruce" == Bruce Momjian writes:
>
> >> 1) select ... from foo, unnest(foo.bar); -- UNNEST is implicitly LATERAL
> [...]
> >> It's point (1) that's the killer - without it, unnest() is just a
> >> trivial shorthand for stuff that can be done anyway; it doesn't
>
Tom Lane wrote:
> Andrew Dunstan writes:
> > Tom Lane wrote:
> >> Peter Eisentraut writes:
> >>> Here is my thinking, and considering that that would basically involve a
> >>> forward-looking design decision right now, I would support dropping the
> >>> cardinality() function from 8.4 (if peopl
> "Bruce" == Bruce Momjian writes:
>> In the absence of feedback to the contrary, I will submit it for
>> the first commitfest of 8.5, and maintain the pgfoundry version
>> for 8.3 and 8.4.
Bruce> Andrew, do you want to add it to the 8.5 commitfest:
I will do so soon but I need to revis
Bruce Momjian writes:
> Tom Lane wrote:
>> It can be, the question is whether we're prepared to break everything
>> under the sun until people add that.
> I think we would first have to agree to issue escape_string_warning
> warnings for code in PL/pgSQL functions, then think about having
> stand
Andrew Gierth wrote:
> > "David" == "David E Wheeler" writes:
>
> > On Mar 24, 2009, at 2:51 PM, Andrew Gierth wrote:
> >> By popular demand, a version of this will go up on pgfoundry for
> >> use with 8.3 etc.
>
> David> Wow. Nice stuff! I hope it's not too late for 8.4?
>
> I personal
Andrew Dunstan writes:
> Tom Lane wrote:
>> Peter Eisentraut writes:
>>> Here is my thinking, and considering that that would basically involve a
>>> forward-looking design decision right now, I would support dropping the
>>> cardinality() function from 8.4 (if people agree that this is in fact
Greg Smith wrote:
> On Mon, 23 Mar 2009, Tom Lane wrote:
>
> > We used to have the stats_reset_on_server_start thingy, which covered
> > that case. When we removed it on the grounds that you could do the
> > same less klugily with pg_stat_reset(), nobody complained about
> > cluster-wide stats...
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Can't that be managed with this CREATE FUNCTION option?:
>> SET configuration_parameter { TO value | = value | FROM CURRENT }
>
> It can be, the question is whether we're prepared to break
everything
> under the sun until people add that.
Well, su
Gregory Stark writes:
> I don't really understand what's going on here.
It's flattening the sub-select, converting
select sum(n),sum(n)
from (select (select count(*) as n from a ) as n
from (select random() as s) as xyzzy) as xyzzy ;
to
select sum((select count(*) from a)), su
Michael Renner wrote:
> Hi,
>
> this is a small update to the first paragraph of the WAL configuration
> chapter, going into more detail WRT redo vs. checkpoint records, since
> the underlying behavior is currently only deducible from the source. I'm
> not perfectly sure if I got everything rig
Tom Lane wrote:
> "Kevin Grittner" writes:
> > Bruce Momjian wrote:
> >> I think the big issue is that having standard_conforming_strings
> >> affect function behavior introduces the same problems we have had in
> >> the past of having a GUC affect function behavior.
>
> > Can't that be managed
"Kevin Grittner" writes:
> Bruce Momjian wrote:
>> I think the big issue is that having standard_conforming_strings
>> affect function behavior introduces the same problems we have had in
>> the past of having a GUC affect function behavior.
> Can't that be managed with this CREATE FUNCTION opt
Bruce Momjian wrote:
> standard_conforming_strings was added in Postgres 8.1, and
> escape_string_warning was enabled in 8.2.
Other way around -- the warning was available in 8.1; the standard
character string literals were available in 8.2.
> I think the big issue is that having standard_confo
On Thu, Apr 9, 2009 at 11:16 AM, Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> Tom Lane wrote:
>> > plpgsql does not consider standard_conforming_strings --- it still uses
>> > backslash escaping in its function bodies regardless. Since the
>> > language itself is not standardized, I see no p
Peter Eisentraut wrote:
> Tom Lane wrote:
> > plpgsql does not consider standard_conforming_strings --- it still uses
> > backslash escaping in its function bodies regardless. Since the
> > language itself is not standardized, I see no particular reason that
> > standard_conforming_strings should
We have an API definition by which extractQuery can distinguish "all
match" from "no match". If we just legislate that "some match" isn't
a valid behavior for zero-key queries, then the code is correct and the
Right now I don't see an example with zero keys and "some match", consistent
method
On Thursday 09 April 2009 16:04:32 Greg Stark wrote:
> Hm, I may have made an assumption here which might be wrong. I assumed
> the original English strings were updated regularly whenever we made a
> release or even more often. Even if no translator was available to add
> translations for them. Or
2009/4/9 Teodor Sigaev :
> contains - all elements of second array are contained in the first one.
> Empty array has no element, so it can't be contained.
That sounds wrong. A B should surely always be true if B is
empty. ie "for all x, x in B implies x in A". Or put another way,
"contains" just
While I was testing this I realized that I wasn't getting quite the same
answers :-(. In particular, it seems that the core operators consider
an empty array to be contained in anything else, while intarray will
only return true for two nonempty arrays.
Urgh. We (with Oleg) digged a bit around
On Thu, Apr 9, 2009 at 1:29 PM, Peter Eisentraut wrote:
> It gets updated when someone with the language skills and interest updates it.
> :-/ As the header tells you, this wasn't recently:
>
> "POT-Creation-Date: 2003-09-22 23:33+0200\n"
> "PO-Revision-Date: 2003-09-22 23:05+0100\n"
>
> I guess
On Wed, Apr 08, 2009 at 08:16:52PM -0400, Tom Lane wrote:
> Sam Mason writes:
> > On Wed, Apr 08, 2009 at 06:11:59PM -0400, Tom Lane wrote:
> >> Anyway, I revised this a bit and applied to HEAD.
>
> > I've not tested; but your changes look as though they will break:
> > SELECT 'Infinity'::float
This query surprised me. I expected us to do the Aggregate once for all the
aggregate functions in the select target which is what normally happens. If I
simplify the query further it actually does so.
I don't really understand what's going on here. It can't be the volatile
random() because in f
Fujii Masao wrote:
Hi,
On Wed, Apr 8, 2009 at 6:56 AM, Guillaume Smet wrote:
On Fri, Apr 3, 2009 at 5:42 AM, Fujii Masao wrote:
Here is the patch;
- Smart failover is chosen if the trigger file labeled "smart" or
an empty one exists.
- Fast failover is chosen if the trigger file labeled "fa
On Thursday 09 April 2009 12:55:40 Gregory Stark wrote:
> I noticed that the Croatian msgid string seems not to match the other
> languages. Did this message change recently? Does this get updated only
> when we reach beta and declare a string freeze?
It gets updated when someone with the language
Tom Lane wrote:
Peter Eisentraut writes:
Here is my thinking, and considering that that would basically involve a
forward-looking design decision right now, I would support dropping the
cardinality() function from 8.4 (if people agree that this is in fact the
design decision to make).
Peter Eisentraut wrote:
On Thursday 02 April 2009 21:38:06 Tom Lane wrote:
Heikki Linnakangas writes:
Now, what about the idea of providing a shorthand LOCALE='foo',
mirroring --locale=foo initdb option? It seems like a good idea, because
you almost never want to set LC_COLLATE and LC_CTYPE di
h
and dtrace probes, but I'll submit it to the next commit-fest
for the record.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
profiler-20090409.tar.gz
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
I happen to be doing this grep (the error message could perhaps use a HINT as
I couldn't figure out how to satisfy it...)
I noticed that the Croatian msgid string seems not to match the other
languages. Did this message change recently? Does this get updated only when
we reach beta and declare a
Hi,
On Thu, Apr 9, 2009 at 6:36 PM, Guillaume Smet wrote:
> On Thu, Apr 9, 2009 at 5:00 AM, Fujii Masao wrote:
>> RequestXLogSwitch() doesn't wait until the switched WAL file has
>> actually been archived. So, some WAL files still may not exist in
>> the standby server also after clean shutdown
On Thu, Apr 9, 2009 at 5:00 AM, Fujii Masao wrote:
> RequestXLogSwitch() doesn't wait until the switched WAL file has
> actually been archived. So, some WAL files still may not exist in
> the standby server also after clean shutdown of the primary.
Thanks for your comment.
RequestXLogSwitch() do
46 matches
Mail list logo
