ugrás a tartalomhoz

plpgsql - recordset változóba mentése

inf · 2013. Júl. 25. (Cs), 13.48
Üdv.

Pgsql 8.4-es verziót használom.

INT4[][] <-> TABLE(id1 INT4, id2 INT4) oda-vissza konverzió kellene, ti. a tömböt már tudom változóba menteni a táblát viszont még nem, legalábbis nekem nem sikerül... :-(

Gondolom az egyik irányt valamilyen SELECT aggregate_2darr(id1,id2) FROM subquery INTO 2darr oldaná meg, a másikat meg SELECT * FROM unnset_2darr(2darr), vagy ehhez hasonló. Tovább sajnos nem jutottam.

off:
Típusok szempontjából kifejezetten átgondolatlan nyelvnek tartom a plpgsql-t, a pgsql dokumentáció meg - mint általában az sql nyelvek dokumentációi - csapnivaló.
‹ MongoDB - hogyan kell/érdemes 'join'-olni Legoptimálisabb termék tulajdonság kezelés ›
 ■
1

Az a helyzet, hogy 2d tömböt

inf · 2013. Júl. 25. (Cs), 17.46
Az a helyzet, hogy 2d tömböt csinálni, vagy bármilyen komplexebb megoldás kb rémálom ebben a nyelvben. Jelenleg az egyedüli működőképes megoldásnak azt tudom elképzelni, hogy ciklussal egyesével végigmegyek a id1-eken, és úgy nézem végig az id2-öket, így csak egy dimenziós tömböt kell használni.
2

Miért akarsz SQL-ben ilyen

MadBence · 2013. Júl. 25. (Cs), 18.10
Miért akarsz SQL-ben ilyen feladatokat megoldani? Nem azt mondom, hogy nem lehet, mert biztosan meg lehet, hiszen bármit meg lehet írni SQL-ben, csak nem feltétlenül érdemes.
3

Én is úgy látom, hogy nem

inf · 2013. Júl. 25. (Cs), 18.27
Én is egyre inkább úgy látom, hogy nem érdemes, de már így kezdtem el. Amúgy végül megírtam. Abból indultam ki, hogy a plpgsql ugyanolyan magasabb szintű nyelv, mint mondjuk javascript, php, perl, stb... amiket szintén lehet használni tárolt eljárások írására. Hát tévedtem. Kalap kaki. Másik nyelvet betenni évi 8k lenne, amit meg nem tartok reális árnak. A másik megoldás, hogy beteszek egy ORM-et, és azzal csináltatok mindent, az ugyanúgy működne, de lassabb lenne a sok egymás után következő sql kérés miatt, a vége meg ott is ugyanaz lenne, hogy kézzel kéne összegányolnom az sql-eket...

Végülis haladok vele, még tanulási fázisban vagyok, össze kell írnom a postgresql rigolyáit.

Pl:

SELECT 1 FROM ARRAY[1] <@ NULL;
SELECT 1 FROM NOT(ARRAY[1] <@ NULL);
Pgsql 8.4 esetében sosem tér vissza eredménnyel. Azért ez elég vicces... De aztán vannak hasonló baromságok még benne olyan hibaüzenetekkel, hogy az életben nem bogozod ki mi van... Ha nem használnék integrációs teszteket totál esélytelen lenne, így csak nehéz...

Azt írják, hogy ez így jó, mert a NOT(null) kiértékelésének eredménye null. Hát meglepő... Nem nagyon értem a logikáját ennek, minden "normális" nyelvnél ez vagy kivételt dob, vagy false-ra konvertálja a null-t. Na majd megszokom...
4

Azt írják, hogy ez így jó,

Joó Ádám · 2013. Júl. 26. (P), 15.37
Azt írják, hogy ez így jó, mert a NOT(null) kiértékelésének eredménye null. Hát meglepő... Nem nagyon értem a logikáját ennek, minden "normális" nyelvnél ez vagy kivételt dob, vagy false-ra konvertálja a null-t.


Ez a következetes viselkedés. SQL-ben minden NULL-on végzett művelet eredménye NULL.

A legjobban egyébként akkor jársz, ha sosem használsz NULL-t.
5

Persze, beszéltem a sráccal,

inf · 2013. Júl. 26. (P), 18.41
Persze, beszéltem a sráccal, azt mondja ilyen az sql szabvány. De ez tök gáz, mert nehéz debuggolni... Az meg megint furcsa, hogy array_agg null-t ad vissza üres tömb helyett... A kettő nem ugyanaz... Leírás ezekről a függvényekről természetesen nincsen, mindössze annyit találtam, hogy egy táblázatban felsorolják őket... Nem is tudom, hogy a mysql vagy a pgsql dokumentációja a rosszabb... Még nem döntöttem el :D Kezd kirajzolódni bennem, hogy nem érdemes sql-el foglalkozni, mert képtelenek összehozni használható dokumentációt, tutorialokat, példákat az ilyen nyelvekhez...