Re: BUG #18774: Not the required output of the query used in the function(delete_from_table1) in postgresql9.4

Dear Team,
Thanks for your kind response.
KIndly find the attached scripts for creating the same issue on postgresql
16.3
Attachments :
1. creating of table (scrCreate.sql)
2. insert statements scripts (insert_statements_new.sql)

*Correct output function : *

CREATE OR REPLACE FUNCTION delete_from_table1(tblname text, sel_tblname
text, wherecon text, colname text, batchsize int)
RETURNS void AS
$$
BEGIN
    -- Construct dynamic SQL for DELETE
    EXECUTE 'DELETE FROM '
        || quote_ident(tblname)
        || ' WHERE '
        || quote_ident(colname)
        || ' IN (SELECT '
        || quote_ident(colname)
        || ' FROM '
        || quote_ident(sel_tblname)
        || ' WHERE '
        || wherecon
        || ' LIMIT '
        || batchsize || ')';
END;
$$ LANGUAGE plpgsql;
SELECT delete_from_table1('commandlog','commandlog','cmdid','cmdtime <
extract(epoch FROM (current_date  - 15))*1000',500);


*Error output function : *
CREATE OR REPLACE FUNCTION delete_from_table2(tblname text, sel_tblname
text, wherecon text, colname text, batchsize int)
RETURNS void AS
$$
BEGIN
    EXECUTE 'DELETE from ' || quote_ident(tblname) ||
        ' where $1 in (select $1 from ' || quote_ident(sel_tblname) ||
        ' where ' || wherecon || ' limit $2 ) '
        USING colname, batchsize;
END;
$$ LANGUAGE plpgsql;

i am running the function as
SELECT delete_from_table2('commandlog','commandlog','cmdid','cmdtime <
extract(epoch FROM (current_date  - 15))*1000',500);

On Thu, Jan 16, 2025 at 9:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Vik Fearing <vik@postgresfriends.org> writes:
> > #18776 appears to have been discarded as a duplicate.  In any case, no
> > one is going to fix a bug in 9.4 which has been EOL since 2020.  I
> > suggest you upgrade to a supported version and re-report the bug if it
> > still exists.
>
> If you do reproduce your problem on a still-in-support branch,
> please re-file with a *self-contained* test case.  It's impossible
> for someone to reverse-engineer your problem from just the two
> function definitions, with no table declarations, sample data,
> calling sequence, or expected vs. actual results.
>
> https://wiki.postgresql.org/wiki/Guide_to_reporting_problems
>
> If it's difficult to cram all the details into our bug-reporting
> form, personally I'd ignore the form and just send mail to
> pgsql-bugs@lists.postgresql.org
>
>                         regards, tom lane
>