Hi Filip,
No not sure 100% when this can happen. This approach will not be possible as in
our application we are programmatically handling these cases and going in other
route to add the record with increased key.
I am using 9.0.4 version.
Thanks
Amar
From: pg
"David Johnston" writes:
> On Behalf Of Samuel Gendler
> I'm happy to modify the proc definition, except that I am unsure how to do
> so other than to rename the variable, which is my least favourite way to do
> that. I'd far rather qualify the name somehow, so that it knows that I am
> refering
On Wed, Sep 21, 2011 at 4:49 PM, David Johnston wrote:
> ** **
>
> *
> *
>
> Not tested but I think all local variables are implicitly scoped to the
> function name so you should be able to do the following:
>
> ** **
>
> WHERE reporting_mgmt.aggregate_timescales_impl.tbl_schema = e.tbl_schem
From: pgsql-sql-ow...@postgresql.org [mailto:pgsql-sql-ow...@postgresql.org]
On Behalf Of Samuel Gendler
Sent: Wednesday, September 21, 2011 7:35 PM
To: pgsql-sql@postgresql.org
Subject: [SQL] ambiguous local variable name in 9.0 proc
I've got a stored proc (which worked fine in 8.3 and 8.4)
I've got a stored proc (which worked fine in 8.3 and 8.4) that is declared
as such:
CREATE OR REPLACE FUNCTION reporting_mgmt.aggregate_timescales_impl (
div_start TIMESTAMP WITHOUT TIME ZONE,
* tbl_schema VARCHAR, *
tbl_root VARCHAR,
fine_timescale VARCHAR,
coars
Boris,
Can you send me your final solution?
I am trying to do something similar and I think I am stuck at the namespace.
Thanks
On Mon, Sep 19, 2011 at 11:49 AM, boris wrote:
> On 09/19/2011 10:49 AM, Rob Sargent wrote:
>>
>> Having a name space in the doc requires it's usage in the query.
>
>
Hi
There is no IGNORE_DUP_KEY equivalent in PostgreSQL.
If you are 100% sure that you want to ignore unique key violations, you can
wrap your INSERT code in PL/PgSQL block and handle the exception yourself.
I mean:
DO $$
BEGIN
INSERT INTO foo (bar,baz) SELECT 42, 666;
EXCEPTION WHEN unique_vio