If the (n rows) is the *only* message that needs it then I think it
would be simpler to just make it (Rows: n) instead. But I wouldn't
be surprised if there were other messages with similar issues.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Robert Haas robertmh...@gmail.com wrote:
Works for me. Especially if you want to think more about ANALYZE before
changing that.
Well, it's something that would be sane to contemplate adding in 8.4.
It's way too late for any of this other stuff to happen in this release.
I'm thinking
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Sergey Burladyan escribió:
maybe build farm can help to test it ?
Yes, I think we should implement it and see what happens with the
buildfarm. If we stand still and do nothing, we won't be any wiser.
The buildfarm is
Greg Stark wrote:
If the (n rows) is the *only* message that needs it then I think it
would be simpler to just make it (Rows: n) instead. But I wouldn't
be surprised if there were other messages with similar issues.
There are a few more, e.g.,
%d index pages have been deleted
%d connections
Peter Eisentraut pete...@gmx.net writes:
Greg Stark wrote:
If the (n rows) is the *only* message that needs it then I think it
would be simpler to just make it (Rows: n) instead. But I wouldn't
be surprised if there were other messages with similar issues.
There are a few more, e.g.,
%d
* Peter Eisentraut pete...@gmx.net [090319 04:21]:
It depends also on what we *want* to target. I originally omitted the
plural support because it was a GNU extension, and I wanted to support
standard gettext implementations as well. (There was also a licensing
consideration.)
Aidan Van Dyk wrote:
* Peter Eisentraut pete...@gmx.net [090319 04:21]:
It depends also on what we *want* to target. I originally omitted the
plural support because it was a GNU extension, and I wanted to support
standard gettext implementations as well. (There was also a licensing
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Greg Stark wrote:
If the (n rows) is the *only* message that needs it then I think it
would be simpler to just make it (Rows: n) instead. But I wouldn't
be surprised if there were other messages with similar issues.
There are a few
Shrish,
It's too late to get this into 8.4 at this point.
Want to start a pgFoundry project around it, so people can play with it
for 8.5?
Also, for people not familiar with Gokul's work, can you give us an
explanation of the theory and implementation for this?
--Josh
--
Sent via
Andrew,
One request I've had is to construct a record (of some supplied
composite type) from an hstore.
I'm not sure if this is even possible; I'm certainly not seeing a way
to implement it. Am I missing something?
Well, presumably you'd try to match hstore tags against the columns of
the
On 3/19/09 1:23 PM, Josh Berkus wrote:
Andrew,
One request I've had is to construct a record (of some supplied
composite type) from an hstore.
I'm not sure if this is even possible; I'm certainly not seeing a way
to implement it. Am I missing something?
Well, presumably you'd try to match
Josh Berkus escribió:
Also, for people not familiar with Gokul's work, can you give us an
explanation of the theory and implementation for this?
It would be helpful to explain how this solves the lack of atomicity of
visibility data updates, which last time I checked was the killer
problem
On Thursday 12 February 2009 17:41:01 Peter Eisentraut wrote:
I know we've already had a discussion on the naming of the pg_restore -m
option, but in any case this description in pg_restore --help is confusing:
-m, --multi-thread=NUM use this many parallel connections to restore
Either it
Peter Eisentraut wrote:
While I think jobs isn't a totally accurate description, I would still
propose to use -j/--jobs for the option name, because it is neutral about the
implementation and has a strong precedent as being used to increase the
parallelization to get the work done faster.
Hi,
Le 19 mars 09 à 21:23, Josh Berkus a écrit :
One request I've had is to construct a record (of some supplied
composite type) from an hstore.
I'm not sure if this is even possible; I'm certainly not seeing a way
to implement it. Am I missing something?
Well, presumably you'd try to match
15 matches
Mail list logo
