postgresql/contrib/lo/lo_test.sql

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

80 lines
1.8 KiB
MySQL
Raw Normal View History

2010-09-20 22:08:53 +02:00
/* contrib/lo/lo_test.sql */
-- Adjust this setting to control where the objects get created.
SET search_path = public;
2000-06-15 21:05:22 +02:00
--
-- This runs some common tests against the type
--
-- It's used just for development
--
-- XXX would be nice to turn this into a proper regression test
--
-- Check what is in pg_largeobject
SELECT count(oid) FROM pg_largeobject_metadata;
2000-06-15 21:05:22 +02:00
-- ignore any errors here - simply drop the table if it already exists
DROP TABLE a;
2000-06-15 21:05:22 +02:00
-- create the test table
CREATE TABLE a (fname name,image lo);
2000-06-15 21:05:22 +02:00
-- insert a null object
INSERT INTO a VALUES ('empty');
2000-06-15 21:05:22 +02:00
-- insert a large object based on a file
INSERT INTO a VALUES ('/etc/group', lo_import('/etc/group')::lo);
2000-06-15 21:05:22 +02:00
-- now select the table
SELECT * FROM a;
2000-06-15 21:05:22 +02:00
-- check that coercion to plain oid works
SELECT *,image::oid from a;
2000-06-15 21:05:22 +02:00
-- now test the trigger
CREATE TRIGGER t_a
BEFORE UPDATE OR DELETE ON a
FOR EACH ROW
EXECUTE PROCEDURE lo_manage(image);
2000-06-15 21:05:22 +02:00
-- insert
INSERT INTO a VALUES ('aa', lo_import('/etc/hosts'));
SELECT * FROM a
WHERE fname LIKE 'aa%';
2000-06-15 21:05:22 +02:00
-- update
UPDATE a SET image=lo_import('/etc/group')::lo
WHERE fname='aa';
SELECT * FROM a
WHERE fname LIKE 'aa%';
2000-06-15 21:05:22 +02:00
-- update the 'empty' row which should be null
UPDATE a SET image=lo_import('/etc/hosts')
WHERE fname='empty';
SELECT * FROM a
WHERE fname LIKE 'empty%';
UPDATE a SET image=null
WHERE fname='empty';
SELECT * FROM a
WHERE fname LIKE 'empty%';
2000-06-15 21:05:22 +02:00
-- delete the entry
DELETE FROM a
WHERE fname='aa';
SELECT * FROM a
WHERE fname LIKE 'aa%';
2000-06-15 21:05:22 +02:00
-- This deletes the table contents. Note, if you comment this out, and
-- expect the drop table to remove the objects, think again. The trigger
-- doesn't get fired by drop table.
DELETE FROM a;
2000-06-15 21:05:22 +02:00
-- finally drop the table
DROP TABLE a;
2000-06-15 21:05:22 +02:00
-- Check what is in pg_largeobject ... if different from original, trouble
SELECT count(oid) FROM pg_largeobject_metadata;
2000-06-15 21:05:22 +02:00
-- end of tests