de meeste databasesystemen bieden een gegevenstype dat ruwe gegevens kan opslaan, en PostgreSQL is geen uitzondering. Ik gebruik de term ruwe gegevens om te betekenen dat de database de structuur of Betekenis van een waarde niet begrijpt. PostgreSQL begrijpt daarentegen wel de structuur en betekenis van andere gegevenstypen. Als je bijvoorbeeld een kolom met een geheel getal definieert, Weet PostgreSQL dat de bytes aan gegevens die je in die kolom plaatst, verondersteld worden een gehele waarde te vertegenwoordigen. PostgreSQL weet wat een integer is?het kan gehele getallen toevoegen, vermenigvuldigen, converteren naar en van string vorm, enzovoort. Ruwe data, aan de andere kant, is gewoon een verzameling van bits?PostgreSQL kan geen enkele betekenis afleiden in de gegevens.

PostgreSQL biedt het type BYTEA voor het opslaan van ruwe gegevens. Een BYTEA kolom kan theoretisch waarden van elke lengte bevatten, maar het lijkt erop dat de maximale lengte 1GB is.

de grootte van een BYTEA-waarde is 4 bytes plus het werkelijke aantal bytes in de waarde.

syntaxis voor letterlijke waarden

het invoeren van een BYTEA-waarde kan een beetje lastig zijn. Een BYTEA letterlijk wordt ingevoerd als een string letterlijk: het is gewoon een string van tekens ingesloten tussen enkele aanhalingstekens. Gezien dat, hoe voer je een BYTEA waarde die een enkele offerte bevat? Als je terugkijkt naar de discussie over letterlijke waarden van strings (eerder in dit hoofdstuk), zul je zien dat je speciale tekens in een stringwaarde kunt opnemen door ze te ontsnappen. In het bijzonder, een enkel citaat kan door ontsnapte in een van de drie manieren:

  • Verdubbelen enkele aanhalingstekens (‘Dit is een enkele quote”‘)

  • Voorafgegaan door de single offerte met een backslash (‘Dit is een enkele quote \”)

  • Zijn de octale waarde van het karakter in plaats daarvan (‘Dit is een enkele quote \047’)

Er zijn twee andere karakters die je moet ontsnappen bij het invoeren van BYTEA literals. Een byte waarvan de waarde nul is (niet het karakter 0, maar de null byte) moet worden escaped, en het backslash karakter moet worden escaped. Je kunt elk teken ontsnappen met het” \\ddd ” formulier (waar ddd een octaal getal is). U kunt ontsnappen aan elk afdrukbare teken met behulp van de” \\c ” formulier. Dus, als je een BYTEA waarde wilt opslaan die een nul byte bevat, kun je het als volgt invoeren:

'This is a zero byte \000'

Als u een BYTEA-waarde wilt opslaan die een backslash bevat, kunt u deze invoeren in een van de volgende formulieren:

'This is a backslash \\''This is also a backslash \134'

als je deze regels vergelijkt met de regels voor het citeren van string literals, zul je merken dat BYTEA literals twee keer zoveel backslash tekens nodig hebben. Dit is een eigenaardigheid van het ontwerp van de PostgreSQL parser. BYTEA literals worden verwerkt door twee verschillende parsers. De belangrijkste PostgreSQL parser ziet een BYTEA letterlijke als een string letterlijke (verslindt de eerste set van backslash karakters). Vervolgens verwerkt de bytea-parser het resultaat, waarbij de tweede reeks backslash-tekens wordt opgeslokt.

dus als je een BYTEA-waarde hebt zoals dit een backslash \ is, citeer je deze als ‘ dit is een backslash\\\\’. Nadat de string parser deze string verwerkt, is het veranderd in ‘ dit is een backslash \\’. De bytea parser uiteindelijk transformeert dit in dit is een backslash \.

ondersteunde Operators

PostgreSQL biedt een enkele bytea-operator: aaneenschakeling. U kunt een BYTEA waarde toevoegen aan een andere BYTEA waarde met behulp van de concatenation (||) operator.

merk op dat je twee BYTEA-waarden niet kunt vergelijken, zelfs niet voor gelijkheid/ongelijkheid. Je kunt natuurlijk een BYTEA waarde omzetten in een andere waarde met behulp van de cast () operator, en dat opent andere operators.

grote objecten

het BYTEA-gegevenstype is momenteel beperkt tot het opslaan van waarden die niet groter zijn dan 1 GB. Als u waarden groter moet opslaan dan in een BYTEA-kolom past, kunt u large-objects gebruiken. Een groot object is een waarde die buiten een tabel wordt opgeslagen. Als u bijvoorbeeld een foto met elke rij in uw tapes-tabel wilt opslaan, voegt u een OID-kolom toe om een verwijzing naar het overeenkomstige grote object te bevatten:

movies=# ALTER TABLE tapes ADD COLUMN photo_id OID;ALTER

elke waarde in de kolom photo_id verwijst naar een item in de systeemtabel pg_largeobject. PostgreSQL biedt een functie die een extern bestand (zoals een JPEG-bestand) in de tabel pg_largeobject zal laden:

movies=# INSERT INTO tapes VALUESmovies-# (movies(# 'AA-55892',movies(# 'Casablanca',movies(# lo_import('/tmp/casablanca.jpg' )movies(# );

de functie lo_import () laadt het benoemde bestand in pg_largeobject en geeft een OID-waarde terug die verwijst naar het grote object. Als je nu deze rij selecteert, zie je de OID, niet de werkelijke bits die deel uitmaken van de foto:

movies=# SELECT * FROM tapes WHERE title = 'Casablanca'; tape_id | title | photo_id----------+------------+---------- MC-68873 | Casablanca | 510699

Als u de foto terug wilt schrijven naar een bestand, kunt u de functie lo_export() gebruiken:

movies=# SELECT lo_export( 510699, '/tmp/Casablanca.jpg' ); lo_export----------- 1(1 row)

gebruik psql ‘ s \ lo_list metacommand om alle grote objecten in de huidige database te zien:

movies=# \lo_list Large objects ID | Description--------+------------- 510699 |(1 row)

u kunt large-objects uit uw database verwijderen met de functie lo_unlink() :

movies=# SELECT lo_unlink( 510699 ); lo_unlink----------- 1(1 row)movies=# \lo_list Large objects ID | Description----+-------------(0 rows)

Hoe kom je bij de werkelijke bits achter de referentie-ID? Kun je dat niet?tenminste niet met psql. Ondersteuning voor grote objecten moet zijn ingebouwd in de clienttoepassing die u gebruikt. psql is een tekst-georiënteerde tool en heeft geen manier om een foto weer te geven, dus het beste dat je kunt doen is om te kijken naar de ruwe gegevens in de pg_largeobject tabel. Een paar clienttoepassingen, zoals het Conjectrix-werkstation, ondersteunen grote objecten en kunnen de ruwe gegevens in de meeste gevallen correct interpreteren.