Just a small example of the fact that people need such
functionality... and will devise other ways, albeit inefficient and
dangerous, to implement the missing feature.
The success of an RDBMS (or any other product for that matter)
depends on how well it strikes the balance between the stand
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Some users of PL/Java make use of a non-default connection from within a
> Trigger in order to do this. In essence, they load the client JDBC package
> into
> the backend to let the backend as such become a client. The second connection
> is then main
Some users of PL/Java make use of a non-default connection from within a Trigger in order to
do this. In essence, they load the client JDBC package into the backend to let the backend
as such become a client. The second connection is then maintained for the lifetime of the
first. Perhaps not the
"Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> Do we have any plans of introducing 'AUTONOMOUS TRANSACTION' like
> feature?
No.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will i
Do we have any plans of introducing 'AUTONOMOUS TRANSACTION' like feature?
Again, it might not be a part of the standard but it is very
helpful in situations like these!!! You can run a trigger with an
autonomous transaction attached to it, which guarantees that the work
done by trigge
Doug,
> But what if the user calls the access function, sees the data, then
> issues a ROLLBACK? The audit record would be rolled back as well (as
> Tom pointed out earlier).
>
> You could use dblink to log to a separate audit database, I suppose.
Or just write to some other non-transational re
Having tinkered a little with PQA, yes, actually. The issue is that the
"message" text can easily be multi-line and contain a vast variety of
special characters. The issue is figuring out where the prefix, the tag
and the message begin and end. And our text log format makes that a PITA.
Try
On Mon, May 15, 2006 at 12:37:34PM -0400, Douglas McNaught wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>
> > On Mon, May 15, 2006 at 10:55:43AM -0500, Hogan, James F. Jr. wrote:
> >> Only specific tables.
> >>
> >> Of the 150 plus existing there are only 8 or 10 that hold sensitive
> >> d
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Mon, May 15, 2006 at 10:55:43AM -0500, Hogan, James F. Jr. wrote:
>> Only specific tables.
>>
>> Of the 150 plus existing there are only 8 or 10 that hold sensitive
>> data.
>
> In that case I'd definately go with the suggestion of creating access
>
On Mon, May 15, 2006 at 10:55:43AM -0500, Hogan, James F. Jr. wrote:
> Only specific tables.
>
> Of the 150 plus existing there are only 8 or 10 that hold sensitive
> data.
In that case I'd definately go with the suggestion of creating access
functions and logging to a table from within them. Jus
.
Cc: Tom Lane; Joshua D. Drake; josh@agliodbs.com; Andrew Dunstan;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] audit table containing Select statements
submitted
How do you hope to avoid this overhead when you're looking to track
information on every single SELECT statement? Or wer
How do you hope to avoid this overhead when you're looking to track
information on every single SELECT statement? Or were you looking to
only log access to some specific tables?
On Mon, May 15, 2006 at 09:38:54AM -0500, Hogan, James F. Jr. wrote:
> Thank you all for the effort you put into respons
hua D. Drake
Cc: josh@agliodbs.com; Andrew Dunstan; Hogan, James F. Jr.;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] audit table containing Select statements
submitted
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Hmmm... well why don't we add log_line_suffix :)
You could do this using Veil, http://pgfoundry.org/projects/veil/, or
something like it. A Veil access function,
http://veil.projects.postgresql.org/curdocs/overview-page.html, could be
used to record every row returned within a query to the user that
requested it. Note that this operates at the
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Hmmm... well why don't we add log_line_suffix :)
Doesn't help; you'd also need logic in there to quote any XML tags
appearing in the message text. At that point, adding a
"log_line_suffix" is a transparent pretense of generality --- what
you might a
Josh Berkus wrote:
Tom,
This argument strikes me as nonsense. You've got a utility that's smart
enough to parse the very-free-format message bodies, but it's going to
be too confused by the log line prefix?
Having tinkered a little with PQA, yes, actually. The issue is that the
"message" t
Tom Lane wrote:
Josh Berkus writes:
Hmmm ... I don't see this as a problem. Just stick the whole message into
a single XML field. This is one area where XML is easier that SQL; since
it's a document format, it has no problem with a great big blob of text.
"Unstructured Data" and all that n
Tom,
> This argument strikes me as nonsense. You've got a utility that's smart
> enough to parse the very-free-format message bodies, but it's going to
> be too confused by the log line prefix?
Having tinkered a little with PQA, yes, actually. The issue is that the
"message" text can easily be
Josh Berkus writes:
> Hmmm ... I don't see this as a problem. Just stick the whole message into
> a single XML field. This is one area where XML is easier that SQL; since
> it's a document format, it has no problem with a great big blob of text.
> "Unstructured Data" and all that nonsense.
Josh Berkus writes:
> Well, the issue with doing this by trigger or RULE is that unlike
> updates and deletes, SELECTS do *not* guarentee single execution. For
> example, if the table is on the loop end of a nested loop, it could be
> fired hundreds or thousands of times. This is the reason w
On Fri, May 12, 2006 at 02:43:56PM -0400, Andrew Dunstan wrote:
> Josh Berkus wrote:
> >Andrew,
> >
> >
> >>The real problem is the message, which is now
> >>from the logging code's point of view basically an opaque string.
> >>Changing that would be a massive undertaking, especially when you thi
Josh Berkus wrote:
Andrew,
The real problem is the message, which is now
from the logging code's point of view basically an opaque string.
Changing that would be a massive undertaking, especially when you think
of the effect on the translators.
Hmmm ... I don't see this as a problem.
Andrew,
> The real problem is the message, which is now
> from the logging code's point of view basically an opaque string.
> Changing that would be a massive undertaking, especially when you think
> of the effect on the translators.
Hmmm ... I don't see this as a problem. Just stick the whole
Josh Berkus wrote:
Secondly, you can use the log. We've discussed on this list making it
possible to log in CSV, XML or other database-digestable format.
Unfortuantely, there doesn't appear to be much momentum behind that; I
don't know that anyone is writing any code presently. Sponsorship?
Hogan, James F. Jr. wrote:
I am trying desperately to find a way to create an audit table to
log...who SELECTED what... as I am dealing with HR data and Health Care
Patient Data
Any help would be greatly appreciated and put to good use in the Austin
Texas Hospitals.
Use statement logging and m
Jim,
I am trying desperately to find a way to create an audit table to
log...who SELECTED what... as I am dealing with HR data and Health Care
Patient Data
Well, the issue with doing this by trigger or RULE is that unlike
updates and deletes, SELECTS do *not* guarentee single execution. For
26 matches
Mail list logo
