Thread: Critical Bug

Critical Bug

From
tejas tank
Date:
Hello,


I have hug postgresql database and when i going to search for a query
with database retrieve with limit of 669 is allow 

If my query fetch records more over 669 records then error is comming...


RROR:  more than one row returned by a subquery used as an expression

********** Error **********

ERROR: more than one row returned by a subquery used as an expression
SQL state: 21000


What should I have to do.?????


Its urgent ....



Thanks,
Tejas L Tank.
Ass. Application Engineer.
OpenERP Pvt. Ltd. 
India

Re: Critical Bug

From
Thom Brown
Date:
On 6 April 2011 11:51, tejas tank <tejas.tank.mca@gmail.com> wrote:
> Hello,
>
>
> I have hug postgresql database and when i going to search for a query
> with database retrieve with limit of 669 is allow
>
> If my query fetch records more over 669 records then error is comming...
>
>
> RROR:  more than one row returned by a subquery used as an expression
>
> ********** Error **********
>
> ERROR: more than one row returned by a subquery used as an expression
> SQL state: 21000
>
>
> What should I have to do.?????

We'd need to see the query, but I suspect you're evaluating a scalar
against a subquery expression, and it's the 670th record which returns
more than 1 record in the subquery.

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Critical Bug

From
Vibhor Kumar
Date:
On Apr 6, 2011, at 4:21 PM, tejas tank wrote:
> ERROR:  more than one row returned by a subquery used as an expression
> ********** Error **********
> ERROR: more than one row returned by a subquery used as an expression
> SQL state: 21000

Error Message is showing that you are using subquery with single comparison operator (like "=" ) in condition clause.

Please share the query which is giving this error message

Thanks & Regards,
Vibhor Kumar
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
vibhor.kumar@enterprisedb.com
Blog:http://vibhork.blogspot.com


Re: Critical Bug

From
Adrian Klaver
Date:
On Wednesday, April 06, 2011 3:51:49 am tejas tank wrote:
> Hello,
>
>
> I have hug postgresql database and when i going to search for a query
> with database retrieve with limit of 669 is allow
>
> If my query fetch records more over 669 records then error is comming...
>
>
> RROR:  more than one row returned by a subquery used as an expression
>
> ********** Error **********
>
> ERROR: more than one row returned by a subquery used as an expression
> SQL state: 21000
>
>
> What should I have to do.?????

Have your subquery only return one row:) Seriously, posting the actual query
would be helpful.

>
>
> Its urgent ....
>
>
>
> Thanks,
> Tejas L Tank.
> Ass. Application Engineer.
> OpenERP Pvt. Ltd.
> India

--
Adrian Klaver
adrian.klaver@gmail.com

Re: Critical Bug

From
tv@fuzzy.cz
Date:
> Hello,
>
>
> I have hug postgresql database and when i going to search for a query
> with database retrieve with limit of 669 is allow
>
> If my query fetch records more over 669 records then error is comming...
>
>
> RROR:  more than one row returned by a subquery used as an expression
>
> ********** Error **********
>
> ERROR: more than one row returned by a subquery used as an expression
> SQL state: 21000
>
>
> What should I have to do.?????
>
>
> Its urgent ....

Fix it.

The 'bug' is actually your falt - you're using a subselect in the place
where an expression is expected, and the subselect returns more than one
row (which is causing the problem).

See for example this:

   SELECT * FROM employees WHERE name = (SELECT name FROM ...)

if the subselect returns more than one row, what should the database do?
The only reasonable solution is to throw an error. The same holds for
subselects used instead of columns, i.e.

   SELECT name, (SELECT ... FROM ...) FROM employees

So you have to find the subselect that returns more than one row and fix
it (rewrite it or something).

regards
Tomas


Re: Critical Bug

From
Craig Ringer
Date:
On 06/04/11 18:51, tejas tank wrote:

> What should I have to do.?????

Read this:
  http://wiki.postgresql.org/wiki/Guide_to_reporting_problems

and try again with a question that includes an example you can
distribute to show others the problem, including any required data, as a
single .sql file. Most likely, you will find the bug in your code while
trying to boil it down to a self-contained test case.

> Its urgent ....

If it's urgent for you, pay a consultant to help you. There are plenty. See:

  http://www.postgresql.org/support/professional_support

Alternately, please respect the time of the people here who're
volunteering to help. Put together a question with enough information
for someone to actually be able to help you. Remember that urgent for
you doesn't make it urgent for anyone else.

  http://wiki.postgresql.org/wiki/Guide_to_reporting_problems

--
Craig Ringer

Re: Critical Bug

From
Allan Kamau
Date:
On Thu, Apr 7, 2011 at 5:50 AM, Craig Ringer
<craig@postnewspapers.com.au> wrote:
> On 06/04/11 18:51, tejas tank wrote:
>
>> What should I have to do.?????
>
> Read this:
>  http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
>
> and try again with a question that includes an example you can
> distribute to show others the problem, including any required data, as a
> single .sql file. Most likely, you will find the bug in your code while
> trying to boil it down to a self-contained test case.
>
>> Its urgent ....
>
> If it's urgent for you, pay a consultant to help you. There are plenty. See:
>
>  http://www.postgresql.org/support/professional_support
>
> Alternately, please respect the time of the people here who're
> volunteering to help. Put together a question with enough information
> for someone to actually be able to help you. Remember that urgent for
> you doesn't make it urgent for anyone else.
>
>  http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
>
> --
> Craig Ringer
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

The current subject is alarming and it sure seems like it is not a
PostgreSQL bug hence it is potentially misleading, and the issue has
not been put to rest as the original author has gone silent and not
responding to the various offers to help on this matter. Maybe it's
time to reformat the subject if it okay.

Allan.