AW: AW: [GENERAL] Addison-Wesley looking for authors
Hello Christopher, [...] Please could you encourage them to do this, or perhaps do it yourself? You seem to have a good knowledge of English. [...] I will see, if I can encourage Addison Wesley to translate the book. Regarding the translation on my own - thank you very much for your compliment ;-) Unfortunately my knowledge of the english language does not go as far as it seems to do ... much of it costs me valuable time to look up the right words. Therefore I do not really think about a translation by myself ... you would surely repent it :-) Best regards, Jens - T-Systems Projektleiter debis Systemhaus GEI GmbH Hausanschrift: Eichhornstrae 3, 10785 Berlin Postanschrift: 10785 Berlin Telefon: (004930) 25 54-32 82 Telefax: (004930) 25 54-31 87 Mobiltelefon: (0170) 167 26 48 E-Mail: [EMAIL PROTECTED] Internet: http://www.t-systems.de
AW: [GENERAL] Addison-Wesley looking for authors
Hello all, hello Bruce, first of all I want to say, that Bruces Book was very well done in my opinion! To answer the question, I already began writing a book about PostgreSQL for Addison Wesley in Germany. It will be released in autumn this year in german language. Perhaps it could be translated by Addison Wesley Corp.? My book does not try to compete with Bruces book (I wouldnt dare to do ;-), it rather does complete the theme while it will contain many, many examples from real life (besides many small examples, the whole book is accompanied by one constantly growing example) and it will contain a rather complex section about PL/pgSQL-programming and application development, also accompanied by many examples. At least I would like to thank Bruce for the offered help - I surely will remember ;-) Best regards, Jens Hartwig - T-Systems Projektleiter debis Systemhaus GEI GmbH Hausanschrift: Eichhornstra?e 3, 10785 Berlin Postanschrift: 10785 Berlin Telefon: (004930) 25 54-32 82 Telefax: (004930) 25 54-31 87 Mobiltelefon: (0170) 167 26 48 E-Mail: [EMAIL PROTECTED] Internet: http://www.t-systems.de -Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im Auftrag von Bruce Momjian Gesendet: Dienstag, 27. Februar 2001 23:29 An: PostgreSQL-announce; PostgreSQL-general Betreff: [GENERAL] Addison-Wesley looking for authors As many of you know, I wrote a PostgreSQL book last year. It is selling very well. (http://www.postgresql.org/docs/awbook.html) Addison-Wesley is looking for more authors to write PostgreSQL books. If you are interested, you can write to Stacie Parillo at: [EMAIL PROTECTED] My book took me six months to write. I can answer any questions you may have, and can help you with technical issues involved in writing a book. [...]
Re: [GENERAL] How passwords can be crypted in postgres?
[...] Isn't this just as bad? If you store the encrypted password, that doesn't help you in the slightest in this case, because if you can breach the list of encrypted passwords, you still know what you need to send as the "password" from the front end to let you into the database. [...] If you encrypt the input from the frontend as well and compare the encrypted strings it will not help you to look into the list of encrypted passwords ... or am I wrong? Regards, Jens Hartwig = Jens Hartwig - debis Systemhaus GEI mbH 10875 Berlin Tel. : +49 (0)30 2554-3282 Fax : +49 (0)30 2554-3187 Mobil: +49 (0)170 167-2648 E-Mail : [EMAIL PROTECTED] =
Re: [GENERAL] User Privileges
Hello, the information can be found in the system-table-column PG_CLASS.RELACL: SELECT RELACL FROM PG_CLASS WHERE RELNAME = 't_dummy'; The result seems to be an array of granted permissions, so you should treat it is an array and look for the appropriate user- or group-name. Hope this helps ... Regards, Jens "W. van den Akker" schrieb: How do I retrieve this privilages? I want to disable menu-options within a program. For that I have to retrieve the privilages for some tables. gr, Willem - Original Message - From: "Dan Wilson" [EMAIL PROTECTED] To: "Niral Trivedi" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, December 26, 2000 7:25 PM Subject: Re: [GENERAL] User Privileges For example I have 5 tables in database A. And now I want to give SELECT/UPDATE/INSERT privileges to a user to all 5 tables. But according to documentation, I have to execute 'GRANT' query 3 times(for select/update/insert) per table. meaning total of 15 times That's incorrect... you can do it all in one statement: GRANT select,update,insert TO "username" ON table_1,table_2,table_3,etc http://www.postgresql.org/users-lounge/docs/7.0/user/sql-grant.htm -Dan ========= Jens Hartwig - debis Systemhaus GEI mbH 10875 Berlin Tel. : +49 (0)30 2554-3282 Fax : +49 (0)30 2554-3187 Mobil: +49 (0)170 167-2648 E-Mail : [EMAIL PROTECTED] =
Re: [GENERAL] How I can join between the other database's tables?
Hello all, I think you are both right. The one says that tables which are related enough to be joined should stay in one database and the other says that it could be necessary for many reasons to hold the tables in different databases. Even if I never was in need to join tables from different databases (in this point I agree with Adam Haberlach), we have many applications which use separate databases for lookup-queries or for the sake of synchronization or replication of databases, therefore I absolutely agree with Adam Rossi. In fact, I also would be very content if PostgreSQL would be enabled to work with different databases (perhaps in some future release?). Best regards, Jens Adam Rossi wrote: On Wednesday 27 December 2000 08:44 pm, Adam Haberlach wrote: I'm pretty sure you are right. If your data is related enough to be joined, it should be related enough to be in the same database. I have to disagree. When you start getting into the hundreds of tables, some form of partitioning is helpful for any number of reasons - security, backups, data ownership, management, etc. I have seen oracle installations with hundreds of databases, each with hundreds of tables, and often the users would write queries that linked across databasesfor example linking from the employee table in the HR database to the log tables in an application database. If this installation had been "flattened" to one giant database, it would have been a nightmare. I for one really wish that PostgreSQL had this functionality. It is one of the biggest things that I miss from other databases. [...] = Jens Hartwig - debis Systemhaus GEI mbH 10875 Berlin Tel. : +49 (0)30 2554-3282 Fax : +49 (0)30 2554-3187 Mobil: +49 (0)170 167-2648 E-Mail : [EMAIL PROTECTED] =
Re: [GENERAL] deletion of records before commit doesn't work
Hello all,
I just reproduced the same phenomenon on my installation (PostgreSQL
7.0.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66) and it seems
to me that maybe the index is not correctly actualized while inserting
the record? It seems that any (!) update on blah (before executing the
delete) will solve the problem:
...
insert into blah (subdiv_code) values ('VG');
delete from blah where subdiv_code='VG';
...
= ERROR
...
insert into blah (subdiv_code) values ('VG');
update blah set subdiv_code='VG' where subdiv_code='VG';
delete from blah where subdiv_code='VG';
...
= OK
...
insert into blah (subdiv_code) values ('VG');
update blah set subdiv_code=subdiv_code;
delete from blah where subdiv_code='VG';
...
= OK
...
insert into blah (subdiv_code) values ('VG');
update blah set id=id;
delete from blah where subdiv_code='VG';
...
= OK
Best regards, Jens
Ashley Clark schrieb:
I've come up with this example and I want to know why it does what it
does.
-- snip --
You are now connected to database template1.
CREATE DATABASE
You are now connected to database testing.
psql:test2.sql:11: NOTICE: CREATE TABLE/UNIQUE will create implicit
index 'subdivs_name_key' for table 'subdivs'
psql:test2.sql:11: NOTICE: CREATE TABLE/PRIMARY KEY will create
implicit index 'subdivs_pkey' for table 'subdivs'
CREATE
psql:test2.sql:20: NOTICE: CREATE TABLE will create implicit sequence
'blah_id_seq' for SERIAL column 'blah.id'
psql:test2.sql:20: NOTICE: CREATE TABLE/PRIMARY KEY will create
implicit index 'blah_pkey' for table 'blah'
psql:test2.sql:20: NOTICE: CREATE TABLE will create implicit
trigger(s) for FOREIGN KEY check(s)
CREATE
INSERT 218198 1
BEGIN
INSERT 218199 1
psql:test2.sql:29: ERROR: triggered data change violation on relation
"blah"
ROLLBACK
BEGIN
INSERT 218200 1
UPDATE 1
DELETE 1
ROLLBACK
-- snip --
and the test file is attached.
--
hackers ally
test2.sqlName: test2.sql
Type: Plain Text (text/plain)
Part 1.2Type: application/pgp-signature
=
Jens Hartwig
-
debis Systemhaus GEI mbH
10875 Berlin
Tel. : +49 (0)30 2554-3282
Fax : +49 (0)30 2554-3187
Mobil: +49 (0)170 167-2648
E-Mail : [EMAIL PROTECTED]
=
[GENERAL] Damaged table pg_access
Hello all, when I try to access the system-table "pg_class", I get the following error: zeda=# select * from pg_class; NOTICE: get_groname: group 1 not found pqReadData() -- backend closed the channel unexpectedly. This probably means the backend terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. !# What happened? Is there any way to repare the damaged table? Thanks in advance for all of you, who spend their valuable time! Best regards, Jens = Jens Hartwig - debis Systemhaus GEI mbH 10875 Berlin Tel. : +49 (0)30 2554-3282 Fax : +49 (0)30 2554-3187 Mobil: +49 (0)170 167-2648 E-Mail : [EMAIL PROTECTED] =
