• Tom Lane's avatar
    Fix checking of query type in plpgsql's RETURN QUERY command. · e0eba586
    Tom Lane authored
    Prior to v14, we insisted that the query in RETURN QUERY be of a type
    that returns tuples.  (For instance, INSERT RETURNING was allowed,
    but not plain INSERT.)  That happened indirectly because we opened a
    cursor for the query, so spi.c checked SPI_is_cursor_plan().  As a
    consequence, the error message wasn't terribly on-point, but at least
    it was there.
    
    Commit 2f48ede0 lost this detail.  Instead, plain RETURN QUERY
    insisted that the query be a SELECT (by checking for SPI_OK_SELECT)
    while RETURN QUERY EXECUTE failed to check the query type at all.
    Neither of these changes was intended.
    
    The only convenient place to check this in the EXECUTE case is inside
    _SPI_execute_plan, because we haven't done parse analysis until then.
    So we need to pass down a flag saying whether to enforce that the
    query returns tuples.  Fortunately, we can squeeze another boolean
    into struct SPIExecuteOptions without an ABI break, since there's
    padding space there.  (It's unlikely that any extensions would
    already be using this new struct, but preserving ABI in v14 seems
    like a smart idea anyway.)
    
    Within spi.c, it seemed like _SPI_execute_plan's parameter list
    was already ridiculously long, and I didn't want to make it longer.
    So I thought of passing SPIExecuteOptions down as-is, allowing that
    parameter list to become much shorter.  This makes the patch a bit
    more invasive than it might otherwise be, but it's all internal to
    spi.c, so that seems fine.
    
    Per report from Marc Bachmann.  Back-patch to v14 where the
    faulty code came in.
    
    Discussion: https://postgr.es/m/1F2F75F0-27DF-406F-848D-8B50C7EEF06A@gmail.com
    e0eba586
plpgsql.sql 118 KB