Thread

1. parser handling of large object OIDs

   Robert Haas <robertmhaas@gmail.com> — 2010-06-09T21:02:12Z

   gram.y treats large object identifiers inconsistently.  The privileges
   stuff treats them as IConst:
   
               | LARGE_P OBJECT_P Iconst_list
                   {
                       PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
                       n->targtype = ACL_TARGET_OBJECT;
                       n->objtype = ACL_OBJECT_LARGEOBJECT;
                       n->objs = $3;
                       $$ = n;
                   }
   
               | ALTER LARGE_P OBJECT_P Iconst OWNER TO RoleId
                   {
                       AlterOwnerStmt *n = makeNode(AlterOwnerStmt);
                       n->objectType = OBJECT_LARGEOBJECT;
                       n->object = list_make1(makeInteger($4));
                       n->newowner = $7;
                       $$ = (Node *)n;
                   }
   
   But the comment code treats them as NumericOnly.
   
               | COMMENT ON LARGE_P OBJECT_P NumericOnly IS comment_text
                   {
                       CommentStmt *n = makeNode(CommentStmt);
                       n->objtype = OBJECT_LARGEOBJECT;
                       n->objname = list_make1($5);
                       n->objargs = NIL;
                       n->comment = $7;
                       $$ = (Node *) n;
                   }
   
   I believe that the comment code is probably right, because I think
   IConst can only handle values < 2^31, whereas OIDs can be as large as
   2^32-1.
   
   Thoughts?
   
   -- 
   Robert Haas
   EnterpriseDB: http://www.enterprisedb.com
   The Enterprise Postgres Company
   
   

2. Re: parser handling of large object OIDs

   Robert Haas <robertmhaas@gmail.com> — 2010-06-10T00:45:48Z

   On Wed, Jun 9, 2010 at 5:02 PM, Robert Haas <robertmhaas@gmail.com> wrote:
   > I believe that the comment code is probably right, because I think
   > IConst can only handle values < 2^31, whereas OIDs can be as large as
   > 2^32-1.
   
   I investigated this a little more and the above analysis turns out to
   be correct.  ALTER LARGE OBJECT OWNER and GRANT ... ON LARGE OBJECT
   don't work for large objects outside the range of a signed integer.
   Session demonstrating the problem and proposed patch attached.
   
   -- 
   Robert Haas
   EnterpriseDB: http://www.enterprisedb.com
   The Enterprise Postgres Company
   

3. Re: parser handling of large object OIDs

   Tom Lane <tgl@sss.pgh.pa.us> — 2010-06-10T02:26:12Z

   Robert Haas <robertmhaas@gmail.com> writes:
   > On Wed, Jun 9, 2010 at 5:02 PM, Robert Haas <robertmhaas@gmail.com> wrote:
   >> I believe that the comment code is probably right, because I think
   >> IConst can only handle values < 2^31, whereas OIDs can be as large as
   >> 2^32-1.
   
   > I investigated this a little more and the above analysis turns out to
   > be correct.  ALTER LARGE OBJECT OWNER and GRANT ... ON LARGE OBJECT
   > don't work for large objects outside the range of a signed integer.
   
   Yup.
   
   > Session demonstrating the problem and proposed patch attached.
   
   This patch seems extremely grotty, though.  Surely that's not the way we
   were doing it in the comment code?
   
   			regards, tom lane
   
   

4. Re: parser handling of large object OIDs

   Robert Haas <robertmhaas@gmail.com> — 2010-06-10T11:09:27Z

   On Wed, Jun 9, 2010 at 10:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
   > Robert Haas <robertmhaas@gmail.com> writes:
   >> On Wed, Jun 9, 2010 at 5:02 PM, Robert Haas <robertmhaas@gmail.com> wrote:
   >>> I believe that the comment code is probably right, because I think
   >>> IConst can only handle values < 2^31, whereas OIDs can be as large as
   >>> 2^32-1.
   >
   >> I investigated this a little more and the above analysis turns out to
   >> be correct.  ALTER LARGE OBJECT OWNER and GRANT ... ON LARGE OBJECT
   >> don't work for large objects outside the range of a signed integer.
   >
   > Yup.
   >
   >> Session demonstrating the problem and proposed patch attached.
   >
   > This patch seems extremely grotty, though.  Surely that's not the way we
   > were doing it in the comment code?
   
   I pretty much just moved the existing code from CommentLargeObject()
   into a new function oidparse().  I couldn't really figure out where to
   put the oidparse() function so I eventually decided on oid.c, and
   therefore also ripped out the trip through the fmgr layer in favor of
   calling the appropriate code directly.  Other than that it's the same
   code.  I'm open to suggestions, but this is basically just a small bit
   of code rearrangement.
   
   -- 
   Robert Haas
   EnterpriseDB: http://www.enterprisedb.com
   The Enterprise Postgres Company