Hello I have been working in a report based on the query bellow. It works
fine in my development server which is postgres 8.0 but in production I have
postgres 7.3 and I am getting the following error:
SQL Error :
ERROR: Unable to identify an ordering operator '<' for type 'smallint[]'
U
On 1/11/06, Mauricio Fernandez A. <[EMAIL PROTECTED]> wrote:
> Hello I have been working in a report based on the query bellow. It works
> fine in my development server which is postgres 8.0 but in production I have
> postgres 7.3 and I am getting the following error:
>
> SQL Error :
> ERROR: Una
"Mauricio Fernandez A." <[EMAIL PROTECTED]> writes:
> The only strange thing in the query is that ac.potencialpacientes is
> smallint[] (in fact is the only thing with sense I can see in the error
> message) but I am not using the '<' operator as it suggest.
No, but you're trying to GROUP BY ac.po
Stumped: is there any way to set up default values for psql variables
within the .SQL file itself? Obviously, I can do something like:
$ psql -f my_script -v MYVAR=${myvar:-mydefault}
but I would prefer to have the value stored with the .SQL file, e.g. (if
this actually worked):
\set MYVAR COALE
Thanks Jaime, I know, you are right : it´s a very bad idea to develop in
version that is superior to the
one in production, but, I don`t know, you win ;).
And thanks to Tom too, because he told the key phrase "GROUP BY
ac.potencialpacientes", as I can skip that clause, now I get the resu
Hello,
I often create foreign keys with "on delete cascade" so I can
conviniently delete rows in multiple tables which are referenced by (a
chain) of foreign keys. Now I've run into an issue and I'd like to
have some opinions if the current behaviour of PostgreSQL is desired.
If have made my tests
On 1/11/06, Jeff Boes <[EMAIL PROTECTED]> wrote:
> Stumped: is there any way to set up default values for psql variables
> within the .SQL file itself? Obviously, I can do something like:
>
> $ psql -f my_script -v MYVAR=${myvar:-mydefault}
>
> but I would prefer to have the value stored with the .
Dirk Jagdmann <[EMAIL PROTECTED]> writes:
> The idea behind the sample commands below is, that the whole deletion
> should be denied, because a trigger in a cascaded table blocked the
> deletion. The trigger works as expected and prevents rows with a value
> of "5" being deleted from table "b". How
