KaiGai Kohei wrote: > >>> We use "SELECT loid FROM pg_largeobject LIMIT 1" in pg_dump. We could > >>> replace pg_largeobject_metadata instead if we try to fix only pg_dump, > >>> but it's no wonder that any other user applications use such queries. > >>> I think to allow reading loid is a balanced solution. > >> Right, I also remind this query has to be fixed up by other reason right > >> now. > >> If all the large objects are empty, this query can return nothing, even if > >> large object entries are in pg_largeobject_metadata. > > > > "metadata" seems very vague. Can't we come up with a more descriptive > > name? > > What about "property"? > The "metadata" was the suggested name from Robert Haas at the last > commit fest, because we may store any other properties of a large > object in this catalog future.
Well, we usually try to be more specific about what something represents and only later abstract it out if needed, but if everyone else is fine with 'metadata', then just leave it unchanged. > > Also, how will this affect pg_migrator? pg_migrator copies > > pg_largeobject and its index from the old to the new server. Is the > > format inside pg_largeobject changed by this patch? > > The format of pg_largeobject was not touched. Good. > > What happens when > > there is no entry in pg_largeobject_metadata for a specific row? > > In this case, these rows become orphan. > So, I think we need to create an empty large object with same LOID on > pg_migrator. It makes an entry on pg_largeobject_metadata without > writing anything to the pg_largeobject. > I guess rest of migrations are not difference. Correct? Uh, yea, pg_migrator could do that pretty easily. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
