Merge large_object.sql test into largeobject.source.

It seems pretty confusing to have tests named both largeobject and
large_object.  The latter is of very recent vintage (commit ff992c0),
so get rid of it in favor of merging into the former.

Also, enable the LO comment test that was added by commit 70ad7ed,
since the later commit added the then-missing pg_upgrade functionality.
The large_object.sql test case is almost completely redundant with that,
but not quite: it seems like creating a user-defined LO with an OID in
the system range might be an interesting case for pg_upgrade, so let's
keep it.

Like the earlier patch, back-patch to all supported branches.

Discussion: https://postgr.es/m/18665.1500306372@sss.pgh.pa.us

Author: tglsfdc

src/test/regress/expected/large_object.out

@@ -86,10 +86,8 @@ END;
 SELECT lo_from_bytea(0, lo_get(loid)) AS newloid FROM lotest_stash_values
 \gset
 
--- Ideally we'd put a comment on this object for pg_dump testing purposes.
--- But since pg_upgrade fails to preserve large object comments, doing so
--- would break pg_upgrade's regression test.
--- COMMENT ON LARGE OBJECT :newloid IS 'I Wandered Lonely as a Cloud';
+-- Add a comment to it, as well, for pg_dump/pg_upgrade testing.
+COMMENT ON LARGE OBJECT :newloid IS 'I Wandered Lonely as a Cloud';
 
 -- Read out a portion
 BEGIN;
@@ -253,6 +251,13 @@ SELECT lo_from_bytea(0, E'\\xdeadbeef') AS newloid
 SET bytea_output TO hex;
 SELECT lo_get(:newloid);
 
+-- Create one more object that we leave behind for testing pg_dump/pg_upgrade;
+-- this one intentionally has an OID in the system range
+SELECT lo_create(3001);
+
+COMMENT ON LARGE OBJECT 3001 IS 'testing comments';
+
+-- Clean up
 DROP TABLE lotest_stash_values;
 
 DROP ROLE regress_lo_user;

src/test/regress/input/largeobject.source

@@ -90,10 +90,8 @@ END;
 -- it's left behind to help test pg_dump.
 SELECT lo_from_bytea(0, lo_get(loid)) AS newloid FROM lotest_stash_values
 \gset
--- Ideally we'd put a comment on this object for pg_dump testing purposes.
--- But since pg_upgrade fails to preserve large object comments, doing so
--- would break pg_upgrade's regression test.
--- COMMENT ON LARGE OBJECT :newloid IS 'I Wandered Lonely as a Cloud';
+-- Add a comment to it, as well, for pg_dump/pg_upgrade testing.
+COMMENT ON LARGE OBJECT :newloid IS 'I Wandered Lonely as a Cloud';
 -- Read out a portion
 BEGIN;
 UPDATE lotest_stash_values SET fd=lo_open(loid, CAST(x'20000' | x'40000' AS integer));
@@ -469,5 +467,15 @@ SELECT lo_get(:newloid);
  \xdeadbeef
 (1 row)
 
+-- Create one more object that we leave behind for testing pg_dump/pg_upgrade;
+-- this one intentionally has an OID in the system range
+SELECT lo_create(3001);
+ lo_create 
+-----------
+      3001
+(1 row)
+
+COMMENT ON LARGE OBJECT 3001 IS 'testing comments';
+-- Clean up
 DROP TABLE lotest_stash_values;
 DROP ROLE regress_lo_user;

src/test/regress/output/largeobject.source

@@ -90,10 +90,8 @@ END;
 -- it's left behind to help test pg_dump.
 SELECT lo_from_bytea(0, lo_get(loid)) AS newloid FROM lotest_stash_values
 \gset
--- Ideally we'd put a comment on this object for pg_dump testing purposes.
--- But since pg_upgrade fails to preserve large object comments, doing so
--- would break pg_upgrade's regression test.
--- COMMENT ON LARGE OBJECT :newloid IS 'I Wandered Lonely as a Cloud';
+-- Add a comment to it, as well, for pg_dump/pg_upgrade testing.
+COMMENT ON LARGE OBJECT :newloid IS 'I Wandered Lonely as a Cloud';
 -- Read out a portion
 BEGIN;
 UPDATE lotest_stash_values SET fd=lo_open(loid, CAST(x'20000' | x'40000' AS integer));
@@ -469,5 +467,15 @@ SELECT lo_get(:newloid);
  \xdeadbeef
 (1 row)
 
+-- Create one more object that we leave behind for testing pg_dump/pg_upgrade;
+-- this one intentionally has an OID in the system range
+SELECT lo_create(3001);
+ lo_create 
+-----------
+      3001
+(1 row)
+
+COMMENT ON LARGE OBJECT 3001 IS 'testing comments';
+-- Clean up
 DROP TABLE lotest_stash_values;
 DROP ROLE regress_lo_user;

src/test/regress/output/largeobject_1.source

@@ -84,7 +84,7 @@ test: select_into select_distinct select_distinct_on select_implicit select_havi
 # ----------
 # Another group of parallel tests
 # ----------
-test: brin gin gist spgist privileges init_privs security_label collate matview lock replica_identity rowsecurity object_address tablesample groupingsets drop_operator large_object password
+test: brin gin gist spgist privileges init_privs security_label collate matview lock replica_identity rowsecurity object_address tablesample groupingsets drop_operator password
 
 # ----------
 # Another group of parallel tests

src/test/regress/parallel_schedule

@@ -115,12 +115,11 @@ test: matview
 test: lock
 test: replica_identity
 test: rowsecurity
-test: password
 test: object_address
 test: tablesample
 test: groupingsets
 test: drop_operator
-test: large_object
+test: password
 test: alter_generic
 test: alter_operator
 test: misc