[PGSQL/SP] Check of een regel bestaat
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
CREATE OR REPLACE FUNCTION invoice.get_supplier_name(IN invoice_id bigint)
RETURNS character varying(255) AS
$BODY$
DECLARE
p_supplier_id bigint;
p_suppliername character varying(255);
BEGIN
p_supplier_id := 'camper_rental_id FROM invoice.invoice_campersupplier WHERE invoice_id = ' || invoice_id ;
IF p_supplier_id IS NOT NULL THEN
p_suppliername := 'name FROM camper.rentals WHERE id = ' || p_supplier_id;
RETURN p_suppliername;
END IF;
RETURN null;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE
COST 100;
RETURNS character varying(255) AS
$BODY$
DECLARE
p_supplier_id bigint;
p_suppliername character varying(255);
BEGIN
p_supplier_id := 'camper_rental_id FROM invoice.invoice_campersupplier WHERE invoice_id = ' || invoice_id ;
IF p_supplier_id IS NOT NULL THEN
p_suppliername := 'name FROM camper.rentals WHERE id = ' || p_supplier_id;
RETURN p_suppliername;
END IF;
RETURN null;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE
COST 100;
Nu weet ik niet zeker of deze relatie bestaat. Hoe kan ik dit controleren? Ik zit te denken aan een try-catch achtige manier, aangezien dit er met een harde error uiklapt:
Code (php)
1
2
2
ERROR: invalid input syntax for integer: "camper_rental_id FROM invoice.invoice_campersupplier WHERE invoice_id = 13"
CONTEXT: PL/pgSQL function "get_supplier_name" line 7 at assignment
CONTEXT: PL/pgSQL function "get_supplier_name" line 7 at assignment
Ik moet deze check met nog 5 tabellen doen om zo de werkelijke supplier te kunnen achterhalen.
Gewijzigd op 01/01/1970 01:00:00 door yorick17
Ik quote mezelf nog even:
Nu weet ik niet zeker of deze relatie bestaat. Hoe kan ik dit controleren? Ik zit te denken aan een try-catch achtige manier
Daardoor klapt regel 10 in een fout. Wat mogelijk is omdat de rij niet hoeft te bestaan, maar hoe kan ik dit ondervangen?
De foutmelding duidt overigens op een andere fout:
p_supplier_id bigint;
En dan:
p_supplier_id := 'camper_rental_id FROM invoice.invoice_campersupplier WHERE invoice_id = ' || invoice_id ;
Wanneer p_supplier_id van het datatype BIGINT moet zijn, kun je daar onmogelijk een string in gaan zetten. De melding "invalid input syntax for integer: " is dan ook vrij logisch.
Ik snap trouwens niet waarom je 5 tabellen met een stored procedure wilt gaan benaderen om de naam van een supplier te achterhalen. Dat klinkt mij eerder in de oren als een JOIN...
Ik meen toch dat dit een soort van query is:
Code (php)
1
p_supplier_id := 'camper_rental_id FROM invoice.invoice_campersupplier WHERE invoice_id = ' || invoice_id ;
Hierbij is ook de camper_rental_id wel een bigint, echter geeft deze query geen resultaat terug omdat deze rij gewoon niet bestaat in de koppeltabel.
Ik zal iets meer uitleggen over de tabelstructuur:
campersupplier <- camperkoppeltabel <-+ factuur
autosupplier <- carkoppeltabel <-+
ferrysupplier <- ferrykoppeltabel <-+
De factuur kan maar gekoppeld zijn aan één van de suppliers en nu wil ik dus achterhalen welke dat is. Een join zou ook kunnen.
Quote:
Ik meen toch dat dit een soort van query is:
Het is een string en geen query, zie de foutmelding.
Ik zie nergens een EXECUTE, je voert de string dus nergens uit, er wordt dus nergens een query uitgevoerd.
Tip: Gebruik een "gewone" query met een JOIN, dat maakt het leven een heel stuk eenvoudiger. Deze query kun je dan wel weer in een VIEW zetten, dat maakt het later nog eenvoudiger om de data te gebruiken. Tevens veiliger, niemand heeft toegang tot de tabellen nodig. Nooit.
Ps. Jouw datamodel rammelt wat, aparte tabellen voor de camper/auto/ferry-suppliers lijken mij niet handig. Ik kan me voorstellen dat je dan dubbele data moet gaan opslaan. Neem een supplier en noteer dan in een koppeltabel welke producten hij levert. Bv. een auto of een camper.
Het alternatief voor een dergelijke koppeling is de tabelnaam opslaan in een tabel, hier ben ik echter niet zo'n fan van.
Ik keek eroverheen dat het nu inderdaad een string is in plaats van query, hoe stom:S.
In dit geval gewoon voor ieder onderdeel een query maken en dan kijken welke query een resultaat oplevert. Het is niks bijzonders dat een query geen resultaat oplevert, dat is de gewoonste zaak van de wereld.