Hi all,
Arnau <[EMAIL PROTECTED]> writes:
I don't know, we have discovered those two rows but I'm not sure if
there are more. Is there any way to check it?
Update and see if the problem is gone ...
We have done:
update customer_app_config set customer_app_config_id =
customer_app_con
Arnau <[EMAIL PROTECTED]> writes:
>I don't know, we have discovered those two rows but I'm not sure if
> there are more. Is there any way to check it?
Update and see if the problem is gone ...
regards, tom lane
---(end of broadcast)---
Tom Lane wrote:
Arnau <[EMAIL PROTECTED]> writes:
I have postgresql 7.4.2 running on debian and I have the oddest
postgresql behaviour I've ever seen.
Is this specific to these two rows? If so it might be a case of this
bug, which was repaired in 7.4.13:
I don't know, we have discovere
Arnau <[EMAIL PROTECTED]> writes:
>I have postgresql 7.4.2 running on debian and I have the oddest
> postgresql behaviour I've ever seen.
Is this specific to these two rows? If so it might be a case of this
bug, which was repaired in 7.4.13:
http://archives.postgresql.org/pgsql-general/2006
Hi Andrew,
I'm not sure about this for 7.4.2, but I'm running 8.1.3 and when I ran
into a problem like that (having to select two distinct options) the
solution that worked for me was to put the entire or statement within
parentheses. In your case, that would be this:
espsm_asme=# select cu
Arnau,
I'm not sure about this for 7.4.2, but I'm running 8.1.3 and when I ran into
a problem like that (having to select two distinct options) the solution that
worked for me was to put the entire or statement within parentheses. In your
case, that would be this:
espsm_asme=# select cu
Hi all,
I have postgresql 7.4.2 running on debian and I have the oddest
postgresql behaviour I've ever seen.
I do the following queries:
espsm_asme=# select customer_app_config_id, customer_app_config_name
from customer_app_config where customer_app_config_id = 5929 or
customer_app_confi
