On 02/02/2016 07:26 PM, Robert Haas wrote:
On Tue, Feb 2, 2016 at 8:25 PM, Curtis Ruck
wrote:
Additionally Robert, given your professional status, you are by no means an
unbiased contributor in this discussion. Your stance on this matter shows
that you
On 2/2/16 10:34 AM, Joshua D. Drake wrote:
Auditing is a pretty security/enterprisey-related thing that could do
with the "officially considered to of the PostgreSQL project standard
and ready for production" rubber-stamp that tends to go along with most
end-user/admin-oriented stuff shipped in
On 2/2/16 5:00 AM, Simon Riggs wrote:
Since you've written the email here, I'd ask that you join our community
and use your knowledge and passion to make things happen.
+1. Kudos for speaking up in the first place, but it's clear that right
now the biggest thing holding Postgres back is lack
On Tue, Feb 02, 2016 at 08:28:54AM -0800, Joshua D. Drake wrote:
> On 02/02/2016 07:31 AM, curtis.r...@gmail.com wrote:
> >Its not available in rpm or premade binary forms in its current
> >instantiation, not a big deal for me, but it raises the barrier to
> >entry.
> >
> >If it was packaged into
On Tue, Feb 2, 2016 at 5:16 PM, David Steele wrote:
> This sort of confusion is one of the main reasons I pursued inclusion in
> core.
But that's exactly wrong. When there is not agreement on one code
base over another, that's the time it is most important not to pick
one
On 2/2/16 4:50 PM, Michael Banck wrote:
>
> We are looking into packaging pgaudit for Debian.
>
> However, then another question comes up: Should the 2nd Quadrant or the
> Crunchy Data codebase be added to the distribution? Who gets to decide?
For my 2 cents I think that the version I submitted
Its not available in rpm or premade binary forms in its current instantiation,
not a big deal for me, but it raises the barrier to entry.
If it was packaged into an RPM, what would be the process to get it added to
postgresql's yum repositories?
February 2 2016 10:24 AM, "Joshua D. Drake"
On 2/2/16 7:25 PM, Curtis Ruck wrote:
I'm opening to testing and evaluating to see if it meets our compliance
requirements, but I am no where close to being a C developer, or having
C developers that could actually provide a meaningful review. One issue
along this thread already pops up,
On 02/02/2016 02:47 AM, José Luis Tallón wrote:
On 02/02/2016 02:05 AM, Curtis Ruck wrote:
[snip]
P.S., do you know what sucks, having a highly performant PostGIS
database that works great, and being told to move to Oracle or SQL
Server (because they have auditing). Even though they charge
On Tue, Feb 2, 2016 at 1:05 AM, Curtis Ruck
wrote:
> or pay
> EnterpriseDB for their 2 year old version that doesn't have all the
> cool/modern jsonb support.
Just for the record, anyone who pays for our "2 year old version that
doesn't have all the
On 02/02/2016 02:05 AM, Curtis Ruck wrote:
[snip]
P.S., do you know what sucks, having a highly performant PostGIS
database that works great, and being told to move to Oracle or SQL
Server (because they have auditing). Even though they charge extra
for Geospatial support (seriously?) or
On 02/02/2016 08:13 AM, Michael Banck wrote:
On Tue, Feb 02, 2016 at 07:24:23AM -0800, Joshua D. Drake wrote:
PostgreSQL has auditing. It is available now, just not in core. Postgis
isn't available in core either and it seems to do just fine.
I don't really buy that argument. For one, PostGIS
On Tue, Feb 2, 2016 at 11:13 AM, Michael Banck
wrote:
> On Tue, Feb 02, 2016 at 07:24:23AM -0800, Joshua D. Drake wrote:
>> PostgreSQL has auditing. It is available now, just not in core. Postgis
>> isn't available in core either and it seems to do just fine.
>
> I
On Tue, Feb 02, 2016 at 07:24:23AM -0800, Joshua D. Drake wrote:
> PostgreSQL has auditing. It is available now, just not in core. Postgis
> isn't available in core either and it seems to do just fine.
I don't really buy that argument. For one, PostGIS has a pretty narrow
functional use-case
On 02/02/2016 07:31 AM, curtis.r...@gmail.com wrote:
Its not available in rpm or premade binary forms in its current instantiation,
not a big deal for me, but it raises the barrier to entry.
If it was packaged into an RPM, what would be the process to get it added to
postgresql's yum
On 2 February 2016 at 02:05, Curtis Ruck <
curtis.ruck+pgsql.hack...@gmail.com> wrote:
> Just because auditing isn't sexy sharding, parallel partitioning, creative
> indexing (BRIN), or hundreds of thousands of transactions a second, doesn't
> make it any less of a requirement to countless
Robert,
This isn't wrong. I don't see anyone else trying to submit anything in
reference to auditing. Just because there have been multiple
implementations in the past, based on commit histories, there have only
been a few that tried getting into core or contrib (that i can find in
mailing list
On Tue, Feb 2, 2016 at 8:25 PM, Curtis Ruck
wrote:
> Additionally Robert, given your professional status, you are by no means an
> unbiased contributor in this discussion. Your stance on this matter shows
> that you don't necessarily want the open source
So, Noah's excellent response has been ignored (from what my threaded
Gmail view tells me) at this point...
On Tue, Feb 2, 2016 at 6:25 PM, Curtis Ruck <
curtis.ruck+pgsql.hack...@gmail.com> wrote:
> Robert,
>
> This isn't wrong. I don't see anyone else trying to submit anything in
>
On Tue, Feb 02, 2016 at 01:05:46AM +, Curtis Ruck wrote:
> So Auditing, it seems that some people want auditing (myself, David Steele,
> 2nd quadrant, and probably others). I personally love postgresql, but
> until it can meet my annoying compliance requirements, I can't leverage it
> fully
20 matches
Mail list logo