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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Vik Fearing <vik(at)postgresfriends(dot)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(at)lists(dot)postgresql(dot)org
>
> regards, tom lane
>