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 h
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.
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
>
> Eithe
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 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 hs
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
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 pgsql-ha
Tom Lane wrote:
Peter Eisentraut 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.,
Aidan Van Dyk wrote:
* Peter Eisentraut [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.) S
* Peter Eisentraut [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.) Solaris is the "
Peter Eisentraut 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 index
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 connection
Tom Lane wrote:
Alvaro Herrera 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 irrelevant to the fact that some
Robert Haas 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 about t
14 matches
Mail list logo