[postgresql/php] last insert ID

[jsiegmund]

In PHP heb je voor mysql de mogelijkheid een ID terug te halen mysql_insert_id(). Deze functie haalt de laatst gegenereerde id op uit de tabel, best handig.
Nu heb ik wat meer functionaliteit nodig op gebied van triggers etc. die mysql niet biedt, dus ben ik overgestapt op postgres. Deze functie bestaat niet voor postgres, dus moet het met de hand. Ik stuit daarbij op het volgende probleem:

user a insert een rij
user b insert een rij
user a vraagt de hoogste PK op
user b vraagt de hoogste PK op

user a krijgt nu het ID van de rij die user b ingevoegd heeft. Kun je vast oplossen door met lock's oid te werken (nog niet uitgezocht), maar dan moet die tabel weer dicht zonder noodzaak. Is het niet mogelijk om meteen de PK (ID) van de ingevoegde rij terug te krijgen zonder daarbij dingen te moeten afsluiten?

Beware: dit is pas het eerste topic van een lange rij postgresql vragen Waarom is die verdomde handleiding dan ook zo lang

[NMe]

http://us2.php.net/manual/en/function.pg-last-oid.php?

[Vuurvlieg]

Modbreak: :/

Nee, deze reply draagt veel bij aan de discussie...

[ Voor 84% gewijzigd door NMe op 03-10-2005 21:05 ]

[JaWi]

Naast de oplossing van -NMe- kun je ook gebruik maken van sequences; PostgreSQL heeft hier erg goede ondersteuning voor.

[GX]

-NMe- schreef op maandag 03 oktober 2005 @ 20:43:
http://us2.php.net/manual/en/function.pg-last-oid.php?

Is het de OID welke je terug wilt hebben of de primary key van een table? In het laatste geval kan je, als je een goed tableontwerp aangehouden hebt, sequence-id eruit plukken.

[ACM]

Zoals JaWi al zegt. Gebruik sequences, bij voorkeur de short-hand Serial als je een vervanger voor MySQL's auto_increment zoekt.

Na de insert kan je dan gewoon SELECT curval("sequence_naam"); doen en heb je het meest recent toegewezen ID voor die sequence en dus de bijbehorende Serial-primary key. Het is iets meer werk, maar zeker ook flexibeler omdat je kan specificeren van welke sequence (tabel) je de boel wilt hebben.
Die curval is overigens binnen de transactie stabiel, dus als je nadat een andere transactie de waarde heeft aangepast de boel opvraagt heb je dezelfde waarde.

De pg_last_oid raad ik je ten strengste af omdat men in Postgresql bezig is die - meestal overbodige - oids standaard niet, ipv wel, te gebruiken.

[jsiegmund]

Die OIDs heb ik in elke tabel uitgezet, kwam ergens tegen dat het deprecated is en aangezien ik een verse gebruiker ben ga ik me niet verdiepen in oude rommel. Ik heb als PK's dus inderdaad Serials gebruikt met die nextval functie om een nieuwe te genereren, dat lijkt goed te werken. SELECT curval is niet helemaal veilig denk ik (zie bovenstaande rede) maar dat heeft in mijn applicatie echt geen invloed dus ga ik dat maar gebruiken. Had het nu opgelost door de hoogste PK eruit te halen en zelfs dat ging nog redelijk goed in de tests.

@GX: goed tabelontwerp, wat versta je daar onder? Nogal een ruim begrip, maar wanneer kun je die sequence-id NIET gebruiken?

[ACM]

iCe01 schreef op dinsdag 04 oktober 2005 @ 14:29:
SELECT curval is niet helemaal veilig denk ik (zie bovenstaande rede) maar dat heeft in mijn applicatie echt geen invloed dus ga ik dat maar gebruiken.

Euh?

ACM schreef op maandag 03 oktober 2005 @ 22:24:
Die curval is overigens binnen de transactie stabiel, dus als je nadat een andere transactie de waarde heeft aangepast de boel opvraagt heb je dezelfde waarde.

Ik zie dat ik het niet helemaal duidelijk neerzette en ook niet helemaal volledig. Die curval is binnen de connectie stabiel. Dus zolang je niet uitlogt en opnieuw inlogt hou je de waarde die je in die connectie het laatst ingevoerd hebt in curval.

Uiteraard zal als user a een nieuw record in diezelfde connectie insert wel als waarde "hoogste waarde + 1" gebruikt worden en kan ie dat daarna terugvragen, maar ongeacht of er nou 100 of 0 inserts van anderen tussendoor kwamen, de curval blijft de waarde die voor die connectie afgegeven is bewaren.

[jsiegmund]

Ok dat had ik niet helemaal begrepen... duidelijk nu!

Nieuw probleem Ik heb zojuist mod_auth_pgsql geinstalleerd op Apache, allemaal prima gegaan. Nu heb ik een database PROMAS waarin een tabel Gebruiker zit met velden "naam" en "password". In .htaccess kun je vervolgens opgeven dat er gekeken moet worden in de database naar de juiste inlogdata, dus ik heb het volgende ingevuld:

code:

AuthName "My PostgreSQL Authenticator"
AuthType basic

Auth_PG_host 192.168.0.1
Auth_PG_port 5432
Auth_PG_user jasper
Auth_PG_pwd *******
Auth_PG_database PROMAS
Auth_PG_pwd_table Gebruiker
Auth_PG_uid_field naam
Auth_PG_pwd_field password

<LIMIT GET POST>
        require valid-user
</LIMIT>

Werkt niet. Foutmelding in postgres log:

code:

ERROR:  relation "gebruiker" does not exist

Error in httpd log:

code:

[Tue Oct 04 18:10:58 2005] [error] [client 192.168.0.10] PGSQL 3: ERROR:  relation "gebruiker" does not exist\n -- Query: select password from Gebruiker where naam='Jasper'

Query lijkt me toch prima. Had binnen PHP ongeveer hetzelfde probleem, maar dat kon ik oplossen door dubbele quotes rond de tabelnaam / kolomnaam te zetten... hoe zit dat precies?

[jsiegmund]

En jawel: dezelfde SQL opdracht binnen psql uitvoeren geeft dezelfde fout, echter wanneer ik uitvoer:

SQL:

 
SELECT * From "Gebruiker" WHERE naam='Jasper' 

werkt het wel?

Grrr... ligt aan die hoofdletter, dat had ik van tevoren moeten weten

[ Voor 22% gewijzigd door jsiegmund op 04-10-2005 17:18 ]

[jochemd]

iCe01 schreef op dinsdag 04 oktober 2005 @ 17:12:
Grrr... ligt aan die hoofdletter, dat had ik van tevoren moeten weten

Zoals je zelf al aangeeft: handleiding lezen.