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 we don't have
-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 to
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
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 object per log
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
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
On Tue, Aug 26, 2014 at 6:45 PM, Michael Paquier
michael.paqu...@gmail.com 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
Michael Paquier michael.paqu...@gmail.com 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
Peter Geoghegan p...@heroku.com 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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Michael Paquier michael.paqu...@gmail.com 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
On Tue, Aug 26, 2014 at 7:47 PM, Tom Lane t...@sss.pgh.pa.us 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
Stephen Frost sfr...@snowman.net 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
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 is
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net 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
* 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
exactly
Stephen Frost sfr...@snowman.net writes:
Consider an audit system where which columns end up in the audit log are
controlled by issuing ALTER TABLE .. ALTER COLUMN type statements.
blink
I'd like to consider such a thing, but it seems like utter pie in the
sky. Do you really believe that
I wrote:
Stephen Frost sfr...@snowman.net 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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
Consider an audit system where which columns end up in the audit log are
controlled by issuing ALTER TABLE .. ALTER COLUMN type statements.
blink
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 sfr...@snowman.net 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
On Wed, Aug 27, 2014 at 12:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Stephen Frost sfr...@snowman.net 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
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.
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
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
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 wanted to
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. I'm
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
28 matches
Mail list logo
