On 1/14/13 11:19 AM, Peter Geoghegan wrote:
I noticed that when !log_checkpoints, control never reaches the site
where the hook is called, and thus the checkpoint info is not stored.
Is that the intended behaviour of the patch?
I was aware and considered it a defensible situation--that turning
I decided to take a look at this.
On 15 November 2012 09:56, Greg Smith wrote:
> -I modeled the hook here on the logging one that went into 9.2. It's
> defined in its own include file and it gets initialized by the logging
> system. No strong justification for putting it there, it was just simi
2012/12/12 Greg Smith :
> On 11/20/12 8:02 PM, Craig Ringer wrote:
>>
>> On 11/20/2012 04:48 PM, Pavel Stehule wrote:
>
>
>>> I don't like to see current hstore in core - It doesn't support
>>> nesting, it doesn't support different datatypes, it is not well
>>> supported by plpgsql
>>>
>>
>> ... or
On 11/20/12 8:02 PM, Craig Ringer wrote:
On 11/20/2012 04:48 PM, Pavel Stehule wrote:
I don't like to see current hstore in core - It doesn't support
nesting, it doesn't support different datatypes, it is not well
supported by plpgsql
... or by many client libraries, though converting hstor
On 11/20/2012 04:48 PM, Pavel Stehule wrote:
> 2012/11/20 Greg Smith :
>> On 11/16/12 12:20 AM, Craig Ringer wrote:
>>
>>> Not that implementing `hstore_to_json` is exactly hard, mind you, as a
>>> quick search shows: https://gist.github.com/2318757
>>
>> Both pulling hstore more firmly into core a
2012/11/20 Greg Smith :
> On 11/16/12 12:20 AM, Craig Ringer wrote:
>
>> Not that implementing `hstore_to_json` is exactly hard, mind you, as a
>> quick search shows: https://gist.github.com/2318757
>
>
> Both pulling hstore more firmly into core and adopting something like a
> hstore_to_json call
On 11/16/12 12:20 AM, Craig Ringer wrote:
Not that implementing `hstore_to_json` is exactly hard, mind you, as a
quick search shows: https://gist.github.com/2318757
Both pulling hstore more firmly into core and adopting something like a
hstore_to_json call as the preferred UI for timing event
On 11/16/2012 02:26 AM, Josh Berkus wrote:
>> Extending this to save the key/value set and most of the other data I
>> mentioned before is pretty straightforward.
> Why not use Hstore? Seriously?
The only issue I see is that hstore's text format is non-standard, not
widely understood and a pain t
On 11/15/12 10:26 AM, Josh Berkus wrote:
Extending this to save the key/value set and most of the other data I
mentioned before is pretty straightforward.
Why not use Hstore? Seriously?
I just haven't done that part yet. The fact that hstore is the likely
way to do it is why I said it's
Greg Smith wrote:
> -The event queue into a simple array accessed in circular fashion.
> After realizing that output needed to navigate in the opposite order
> of element addition, I ended up just putting all the queue
> navigation code directly into the add/output routines. I'd be happy
> to use
> Extending this to save the key/value set and most of the other data I
> mentioned before is pretty straightforward.
Why not use Hstore? Seriously?
It would require merging Hstore into core, but I don't necessarily see
that as a bad thing.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexp
Attached is a first WIP saving Timing Events via a new hook, grabbed by
a new pg_timing_events contrib module. This only implements a small
portion of the RFP spec I presented earlier this month, and is by no
means finished code looking for a regular review. This is just enough
framework to d
12 matches
Mail list logo
