Thread: BUG #13880: Different procedures in same SQL

BUG #13880: Different procedures in same SQL

From
victor.evangelista@caixa.gov.br
Date:
The following bug has been logged on the website:

Bug reference:      13880
Logged by:          Victor Neves
Email address:      victor.evangelista@caixa.gov.br
PostgreSQL version: 9.1.9
Operating system:   RedHat 4.4.7 x64
Description:

I found a different procedures in same SQL, in postgres 9.1.9.

I create a table, but i dont insert any data, after execute

insert into <table> (namecolum1, namecolum2, namecolum3, namecolum4)
select distinct 'value1', 'value2', 'value3', 'value4'
from <table> where not exists (select 1 from <table> sis where
sis.namecolum2='value2' )

Postgres says: "Query returned successfully: 0 rows affected, 1 ms execution
time."

But if I insert any data in the table and execute the SQL again, the insert
works fine!

If I truncate the table and execute de SQL, postgres says "0 rows affected"
again.

Re: BUG #13880: Different procedures in same SQL

From
"David G. Johnston"
Date:
On Thu, Jan 21, 2016 at 9:53 AM, <victor.evangelista@caixa.gov.br> wrote:

> The following bug has been logged on the website:
>
> Bug reference:      13880
> Logged by:          Victor Neves
> Email address:      victor.evangelista@caixa.gov.br
> PostgreSQL version: 9.1.9
> Operating system:   RedHat 4.4.7 x64
> Description:
>
> I found a different procedures in same SQL, in postgres 9.1.9.
>
> I create a table, but i dont insert any data, after execute
>
> insert into <table> (namecolum1, namecolum2, namecolum3, namecolum4)
> select distinct 'value1', 'value2', 'value3', 'value4'
> from <table> where not exists (select 1 from <table> sis where
> sis.namecolum2=3D'value2' )
>
> Postgres says: "Query returned successfully: 0 rows affected, 1 ms
> execution
> time."
>
> But if I insert any data in the table and execute the SQL again, the inse=
rt
> works fine!
>
> If I truncate the table and execute de SQL, postgres says "0 rows affecte=
d"
> again.
>
>
=E2=80=8BYeah, if "<table>" is empty then a query having "<table>" in its F=
ROM
clause will return zero records.  Period.  That fact that you add "DISTINCT
'literal' AS col" won't change that.

David J.=E2=80=8B