Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YU0UJ-0004V8-Uh for pgsql-sql@arkaria.postgresql.org; Fri, 06 Mar 2015 22:12:56 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YU0UJ-0004s1-AL for pgsql-sql@arkaria.postgresql.org; Fri, 06 Mar 2015 22:12:55 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YU0UI-0004rt-Hv for pgsql-sql@postgresql.org; Fri, 06 Mar 2015 22:12:54 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YU0UA-0004vN-El for pgsql-sql@postgresql.org; Fri, 06 Mar 2015 22:12:53 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6E78E2088F for ; Fri, 6 Mar 2015 17:12:43 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 06 Mar 2015 17:12:44 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=aklaver.com; h= x-sasl-enc:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=NrDq8ShTp9JQY4TQDXO43hugpEU=; b=NBn8I2yu3qFPU1kucF 1nUP7i7fr6F1moQrQ2htvfcHUt7IH6PnShuc1oOrplYkNbT+KGtYE+ekDC314KEa EURIcds7tWspKhm4BXXU0KfOjx02Hqem5lsFafsP6BOoqXF9OUqfgTw6SrJPRsY+ g7+AK+6Wr1FRyRdA7O0cIQxd0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=NrDq8ShTp9JQY4TQDXO43h ugpEU=; b=i/0o/2pEnIq3m/etGwwAd6qG2Qh2Ss7dpUwtJaMglMwmVUS58FbkYD HcUvc4EfHvnumL72AF8a6YWz1cO1I6+PQNRxK+T8712d+YhPRNyOm7bQO4LPUkaW 2R70Sb0rgvvr4usBJo7daNWMS0MS+SLMMQzOgYuNSZq/tMhgG8wfc= X-Sasl-enc: j9LKYurkj+zP6JCqTGOeOKo+VkYbQkowtv9ld1LfLyBa 1425679964 Received: from killi.site (unknown [216.174.214.42]) by mail.messagingengine.com (Postfix) with ESMTPA id 2BC4CC00297; Fri, 6 Mar 2015 17:12:44 -0500 (EST) Message-ID: <54FA265B.5080305@aklaver.com> Date: Fri, 06 Mar 2015 14:12:43 -0800 From: Adrian Klaver User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jason Aleski , pgsql-sql@postgresql.org Subject: Re: Find inconsistencies in data with date range References: <54FA1E61.9000201@gmail.com> In-Reply-To: <54FA1E61.9000201@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org On 03/06/2015 01:38 PM, Jason Aleski wrote: > I know I can do this Java, but I'd rather have this running as a Stored > Procedure. What I am wanting to do is identify and potentially correct > the summary data for date inconsistencies. We have policies/red flag > reports in place to keep this from happening, but we are now cleaning up > history. The query below works on a per store basis, but I'd like to be > able to run this for all stores in the location table. > > I've looked at some procedure codes regarding looping, but everything I > try to create seems to give me problems. THe code I'm trying is also > below. Does anyone have any suggestions on how to accomplish this? > > > > _Working Tables_ > locations - table contains store information, startup date, address, etc > daily_salessummary - table holds daily sales summary by store > (summary should be updated nightly). eod_ts is End of Day Timestamp. > > _Query_ > WITH datelist AS( > SELECT t1.GenDate as gendate, extract(dow from GenDate) AS dayofweek > FROM (SELECT date as GenDate > FROM > generate_series('1985-01-01'::date,CURRENT_TIMESTAMP::date,'1 > day'::interval) date > ) AS t1 > ) > SELECT gendate FROM datelist AS t1 > WHERE gendate NOT IN (SELECT t1.eod_ts FROM daily_salessummary AS t1 > JOIN locations AS t2 ON t1.location_id = t2.row_id > WHERE t2.locationCode = 'US_FL_TAMPA_141') > > AND gendate > (SELECT start_date FROM locations WHERE locationCode = > 'US_FL_TAMPA_141') First in above and in variation below I would probably do some alias renaming. I pretty sure t1 means different things throughout the query, but is hard to follow exactly what. > > > _Desired Output_ - could output to an exceptions table > StoreCode 'US_FL_TAMA_141' missing daily summary for 1998-01-01 > StoreCode 'MX_OAXACA_SALINA_8344' missing daily summary for 2011-06-05 > > > _ProcedureSQL_ (contains unknown errors) > DECLARE > CURSOR location_table IS > SELECT locationCode FROM locations; > BEGIN > FOR thisSymbol IN ticker_tables LOOP > EXECUTE IMMEDIATE 'WITH datelist AS( > SELECT t1.GenDate as > gendate, extract(dow from GenDate) AS dayofweek > FROM (SELECT date as > GenDate > FROM > generate_series('1985-01-01'::date,CURRENT_TIMESTAMP::date,'1 > day'::interval) date > ) AS t1 > ) > SELECT gendate FROM > datelist AS t1 > WHERE gendate NOT IN > (SELECT t1.eod_ts FROM daily_salessummary AS t1 > JOIN locations AS t2 ON t1.location_id = t2.row_id > WHERE t2.locationCode = '' || location_table.locationCode || '') > AND gendate > (SELECT > start_date FROM locations WHERE locationCode = '' || > location_table.locationCode || '')'; > END LOOP; > END; I do not use cursors enough in plpgsql to be sure, but I think the above definition is incorrect: http://www.postgresql.org/docs/9.4/interactive/plpgsql-cursors.html To reduce the moving parts I would write the function without the cursor and just hardwire the location information to start with to get a working sample. > > > > -- > Jason Aleski / IT Specialist > -- Adrian Klaver adrian.klaver@aklaver.com -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql