On 08/27/2014 09:53 AM, Andres Freund wrote:
>> > Perhaps instead of doing this in-core it would be better to make log
>> > handling more extensible? I'm thinking add a specific "binary" format and
>> > an external tool that can parse that and do whatever the user wants with
>> > it. That means
On 27/08/14 18:53, Andres Freund wrote:
On 2014-08-26 23:04:48 -0500, Jim Nasby wrote:
On 8/26/14, 8:45 PM, Michael Paquier wrote:
Hi all,
As mentioned here, we support multiple logging format:
http://www.postgresql.org/docs/devel/static/runtime-config-logging.html
Now what about a json format
On 2014-08-26 23:04:48 -0500, Jim Nasby wrote:
> On 8/26/14, 8:45 PM, Michael Paquier wrote:
> >Hi all,
> >
> >As mentioned here, we support multiple logging format:
> >http://www.postgresql.org/docs/devel/static/runtime-config-logging.html
> >Now what about a json format logging with one json obje
On 8/26/14, 8:45 PM, Michael Paquier wrote:
Hi all,
As mentioned here, we support multiple logging format:
http://www.postgresql.org/docs/devel/static/runtime-config-logging.html
Now what about a json format logging with one json object per log entry?
A single json entry would need more space t
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Stephen Frost wrote:
> To try to clarify that a bit, as it comes across as rather opaque even
> on my re-reading, consider a case where you can't have the
> "credit_card_number" field ever exported to an audit or log file, but
> you're required
On Wed, Aug 27, 2014 at 12:48 PM, Tom Lane wrote:
> I wrote:
>> Stephen Frost writes:
>>> Consider an audit system where which columns end up in the audit log are
>>> controlled by issuing ALTER TABLE .. ALTER COLUMN type statements.
>
>> I'd like to consider such a thing, but it seems like utter
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I wrote:
> > Stephen Frost writes:
> >> Consider an audit system where which columns end up in the audit log are
> >> controlled by issuing ALTER TABLE .. ALTER COLUMN type statements.
>
> > I'd like to consider such a thing, but it seems like utter pie in
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Consider an audit system where which columns end up in the audit log are
> > controlled by issuing ALTER TABLE .. ALTER COLUMN type statements.
>
>
>
> I'd like to consider such a thing, but it seems like utter pie in the
> sky.
I wrote:
> Stephen Frost writes:
>> Consider an audit system where which columns end up in the audit log are
>> controlled by issuing ALTER TABLE .. ALTER COLUMN type statements.
> I'd like to consider such a thing, but it seems like utter pie in the
> sky.
On further thought: the existing postm
Stephen Frost writes:
> Consider an audit system where which columns end up in the audit log are
> controlled by issuing ALTER TABLE .. ALTER COLUMN type statements.
I'd like to consider such a thing, but it seems like utter pie in the
sky. Do you really believe that elog() could know enough a
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
>
> > The flip side is that there are absolutely production cases where what
> > we output is either too little or too much- being able to control that
> > and then have the (filtered) result in JSON would be more-or-less
>
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > The flip side is that there are absolutely production cases where what
> > we output is either too little or too much- being able to control that
> > and then have the (filtered) result in JSON would be more-or-less
> > exact
Stephen Frost wrote:
> The flip side is that there are absolutely production cases where what
> we output is either too little or too much- being able to control that
> and then have the (filtered) result in JSON would be more-or-less
> exactly what a client of ours is looking for.
My impression
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I think the extra representational overhead is already a good reason to
>> say "no". There is not any production scenario I've ever heard of where
>> log output volume isn't a consideration.
> The flip side is that there are absol
On Tue, Aug 26, 2014 at 7:47 PM, Tom Lane wrote:
>> I think that it would be a good beginner's project to make pprint()
>> print JSON.
>
> There's something to be said for that (or, really, for any standardized
> widely-popular textual data format; but JSON is a perfectly reasonable
> candidate).
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Paquier writes:
> > Now what about a json format logging with one json object per log entry?
>
> > A single json entry would need more space than a csv one as we need to
> > track the field names with their values. Also, there is always the
> > arg
Peter Geoghegan writes:
> I think that it would be a good beginner's project to make pprint()
> print JSON.
There's something to be said for that (or, really, for any standardized
widely-popular textual data format; but JSON is a perfectly reasonable
candidate).
> The existing infrastructure is
Michael Paquier writes:
> Now what about a json format logging with one json object per log entry?
> A single json entry would need more space than a csv one as we need to
> track the field names with their values. Also, there is always the
> argument that if an application needs json-format logs
On Tue, Aug 26, 2014 at 6:45 PM, Michael Paquier
wrote:
> Thoughts?
I think that it would be a good beginner's project to make pprint()
print JSON. I spend enough time staring at its output that I've often
wished I could expand and collapse each part using my text editor's
folds feature. I guess
Hi all,
As mentioned here, we support multiple logging format:
http://www.postgresql.org/docs/devel/static/runtime-config-logging.html
Now what about a json format logging with one json object per log entry?
A single json entry would need more space than a csv one as we need to
track the field na
David Fetter wrote:
Folks,
Perhaps I've misunderstood this, but in PostgreSQL 8.3.5, I get
disparate results from ~ and SIMILAR TO. For example:
This gives an unexpected result:
davidfet...@davidfetter=# SELECT 'abc' SIMILAR TO '^[a]';
?column?
--
f
(1 row)
This one is what I exp
David Fetter wrote:
> Folks,
>
> Perhaps I've misunderstood this, but in PostgreSQL 8.3.5, I get
> disparate results from ~ and SIMILAR TO. For example:
Did you read the docs? ^ is not an anchor.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replica
Folks,
Perhaps I've misunderstood this, but in PostgreSQL 8.3.5, I get
disparate results from ~ and SIMILAR TO. For example:
This gives an unexpected result:
davidfet...@davidfetter=# SELECT 'abc' SIMILAR TO '^[a]';
?column?
--
f
(1 row)
This one is what I expected.
davidfet...@dav
Bruce Momjian writes:
> Is this a TODO?
It's a must-fix for 7.3, but frankly I don't see how we could justify
making the required extensive changes during beta. I suggest that we keep
the parser support and throw an error when it's invoked.
--
Peter Eisentraut [EMAIL PROTECTED]
--
Is this a TODO?
---
Peter Eisentraut wrote:
> Thomas Lockhart writes:
>
> > > SIMILAR TO doesn't implement the SQL standard, it's only a wrapper around
> > > the POSIX regexp matching, which is wrong. I thought someone wa
Thomas Lockhart writes:
> > SIMILAR TO doesn't implement the SQL standard, it's only a wrapper around
> > the POSIX regexp matching, which is wrong. I thought someone wanted to
> > fix that, but if it's not happening it should be removed.
>
> Please be specific on what you would consider correct
> SIMILAR TO doesn't implement the SQL standard, it's only a wrapper around
> the POSIX regexp matching, which is wrong. I thought someone wanted to
> fix that, but if it's not happening it should be removed.
Please be specific on what you would consider correct. I'm not recalling
any details of
Anyone read the [NOT] SIMILAR TO syntax for regular expressions? Looks like
it might be close to an SQL standard synonym for [!]~. I don't know if it
can match the case insensitive ops though.
--
Robert B. Easter [EMAIL PROTECTED] -
-- CompTechNews Message Board http://www.
28 matches
Mail list logo
