On Thursday 13 September 2001 15:34, Ryan Mahoney wrote:
> What is it? 8) is it middleware? Is it pre-built applications? I'm
> confused!
It is sort of an application framework and builder.
IMHO not very useful, as it does not support any real world programming
language apart from Java (supp
On Wednesday 29 August 2001 20:05, you wrote:
> hi,
> Idon't know the best way but how about a quick insert in a temp table and
> adding 1 to the inserted oid column each time the trigger will run.!
> regards
As you don't know how many users access the server concurrently and in which
order they
On Tuesday 14 August 2001 02:25, you wrote:
> I still think that expanding transaction IDs (XIDs) to 8 bytes is no help.
> Aside from portability and performance issues, allowing pg_log to grow
> without bound just isn't gonna do. So, the name of the game is to recycle
But what about all of us
On Thursday 19 July 2001 06:08, you wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think it should be off on user tables by default, but kept on system
> tables just for completeness. It could be added at table creation time
> or from ALTER TABLEL ADD. It seems we just use them too mu
On Thursday 19 July 2001 06:08, you wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think it should be off on user tables by default, but kept on system
> tables just for completeness. It could be added at table creation time
> or from ALTER TABLEL ADD. It seems we just use them too m
Greetings,
I need to implement a full write audit trail (every write access needs to be
logged as a complete SQL statement with timestamp, user and host) in our
database.
Which is the most efficient way to do this on the server side in Postgres? I
tried to find something relevant in the docum
> I downloaded it. The directories are two characters in length, the
> files are numbers, and it is a mixture of C++, Python, and Pascal. Need
> I say more. :-)
1.) What is wrong with a mixture of C++, Python and Pascal? Nothing IMHO.
2.) The directory structure is probably the consequence of
On Sunday 14 January 2001 04:49, Tom Lane wrote:
> A row-level CRC might be useful for this, but it would have to be on
> the data only (not the tuple commit-status bits). It'd be totally
> impractical with a block CRC, I think. To do it with a block CRC, every
> time you changed *anything* in
rmation.
> The ability to "attach" (MS-Access parlance) a table or a view from
> another database is quite helpful. And I think that it has a lot of
> applications outside my (quite limited) realm.
It is quite disastrous for referential integrity.
--
==
Dr. Horst Herb, coordinator gnumed project, Australia
==
On Monday 01 January 2001 01:42, Ferruccio Zamuner wrote:
> Hi,
>
> some months ago I've asked for a suggestion for this bug:
>
> create table a (
>id serial primary key,
>something text
> );
>
> create table b (
>morething text
> ) inherits (a);
>
> create table c (
>
Can anybodt give me a few examples on how to use heap_modifytuple()
efficiently when I do NOT want to modify an attribute through a postgres
function?
All the examples given in the source seem to use some return of a postgres
function (like current user etc). I just want to insert strings into
I stated this before, but I did not get a helpful answer. I might have
misunderstood tghe documentation on foreign keys:
create table global(id serial);
create table child(anything text) inherits(global);
insert into child(anything) values ('test);
Now, a select * from child shows
id anyth
O
> > Always remember that a psotgres data base on the harddisk can be
> > manipulated accidentally / maliciously without postgres even running.
> > These are the cases where you need row level CRCs.
>
> "There is no security without physical security." If somebody can
> change the row contents,
On Sunday 10 December 2000 17:35, you wrote:
> > 1.) A CRC is _not_ stronger than a hash. CRC is a subset of the hash
> > domain, defined as "a fast error-check hash based on mod 2 polynomial
> > operations" which has typically no crypto strength (and does not need it
> > either for most purposes
Ooops, sorry, error in this example:
> The following example worked in previous versions (7.0.2 was the last I
> tested), but not in 7.1 any more:
>
> create table parent (
> global_id serial
> );
>
> create table child (
> anything text
> ) inherits (parent);
>
> create table foreign (
> fk_id in
The following example worked in previous versions (7.0.2 was the last I
tested), but not in 7.1 any more:
create table parent (
global_id serial
);
create table child (
anything text
) inherits (parent);
create table foreign (
fk_id int4 references parent(global_id) on update cascade on delete
Sorry, but I just found out that many of my mails bounced because I was using
my secondary email address =8-0
-- Forwarded Message --
Subject: Re: [HACKERS] CRC, hash & Co.
Date: Mon, 11 Dec 2000 07:13:31 +1100
From: Horst Herb <[EMAIL PROTECTED]>
To: [EMAIL PROTE
There have been some misconceptions in previous mails.
1.) A CRC is _not_ stronger than a hash. CRC is a subset of the hash domain,
defined as "a fast error-check hash based on mod 2 polynomial operations"
which has typically no crypto strength (and does not need it either for most
purposes).
2.
> I think a row-level CRC is rather pointless. Perhaps it'd be a good
> idea to have a disk-page-level CRC, though. That would check the rows
> on the page *and* allow catching errors in the page and tuple overhead
> structures, which row-level CRCs would not cover.
row level is neccessary to b
> I suspect that you are really looking at the problem from the wrong end.
> CRC checking should not need to be done by the database user, with a fancy
> type. The postgres server itself should guarantee data integrity - you
> shouldn't have to worry about it in userland.
I agree in principle. H
I believe that there are many good points to have CRC facilities "built
int", and I failed to detect any arguments against it. In my domain (the
medical domain) we simply can't use data without "proof" of integrity
("proof" as in highest possible level of confidence within reasonable
effort)
Th
> > (I'd also like to see CRCs on all the table blocks as well; is there
> > a place to put them?)
>
> Do we need it? "physical log" feature suggested by Andreas will protect
> us from non atomic data block writes.
CRCs are neccessary because of glitches, hardware failures, operating system
bugs,
P.S.: I would volunteer to integrate CRC routines into postgres if somebody
points me in the right direction in the source code.
Horst
> This may be implemented very fast (if someone points me where
> I can find CRC func). And I could implement "physical log"
> till next monday.
I have been experimenting with CRCs for the past 6 month in our database for
internal logging purposes. Downloaded a lot of hash libraries, tried
differ
> > How long until the entire code base gets co-opted?
>
> Yeah so what? Nobody's forcing you to use, buy, or pay attention to any
> such efforts. The market will determine whether the release model of
> PostgreSQL, Inc. appeals to customers. Open source software is a
> privilege, and nobody ha
> > Branding. Phone support lines. Legal departments/Lawsuit prevention.
Figuring
> > out how to prevent open source from stealing the thunder by duplicating
^^
> > features. And building a _product_.
Oops. You didn't really mean that,
> server, before we accept MSSQL, we use this method to test if MSSQL can
endure this kind of strik,
> it's OK, all databases are safely recovered, we can continue our work. we
are a stock exchange company,
And how exactly did you test the integrity of your data? Unless every single
record has g
> Btw, the concept of checksumming rows is kinda new to me.
> I needed this to store passwords on a table, so sorry if I
> cant be more help. But I am a litte bit curious, why is it
> needed? Simple checksumming (crc32/md5) does not help malicious
> changing of data, only hardware failures, but
> > > http://www.l-t.ee/marko/pgsql/pgcrypto-0.1.tar.gz(11k)
First of all, thankd for tis contribution. I had impemented a similar thing for my own
purposes. A problem I still have is using the digest for "checksumming" rows in my
tables - which is a 'MUST' for medico-legal reasons in my
Would it be possible to implement "generic triggers", that is a trigger function for a
whole data base and not only for a single table?
Any elegant way to implement this with existing facilities (other than writing a
trigger function for each of my 250+ tables) ?
Horst
30 matches
Mail list logo
