Yes but it didn’t sink in but the two table join idea does make sense – I’ll
give that a try. THANK YOU.
From: David G. Johnston
Sent: Saturday, November 21, 2020 11:25 AM
To: Hagen Finley
Cc: pgsql-general@lists.postgresql.org
Subject: Re: INSERT Trigger to check for existing records
O
On Saturday, November 21, 2020, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Saturday, November 21, 2020, Hagen Finley wrote:
>
>> David,
>>
>> That's an interesting idea. I WOULD like to retain the OLD records that
>> are the same and only INSERT new or changed records. Is there
On Saturday, November 21, 2020, Hagen Finley wrote:
> David,
>
> That's an interesting idea. I WOULD like to retain the OLD records that
> are the same and only INSERT new or changed records. Is there a way to
> compare the old and the new records without a trigger?
>
A where clause?
David J.
On 11/21/20 9:47 AM, Hagen Finley wrote:
Thanks so much Adrian,
I like this approach but as you indicated it doesn't actually NULL the
INSERT.
It should cause the INSERT not to happen if a row exists with the same
values for ndealid, revusd and stage. Are you seeing an INSERT for those
cond
David,
That's an interesting idea. I WOULD like to retain the OLD records that
are the same and only INSERT new or changed records. Is there a way to
compare the old and the new records without a trigger?
Hagen
On 11/21/20 9:15 AM, David G. Johnston wrote:
On Saturday, November 21, 2020,
Thanks so much Adrian,
I like this approach but as you indicated it doesn't actually NULL the
INSERT.
Could we UPDATE the existing record (per my fledgling chk UPDATE and
then RETURN NULL? (More proof I don't know what I am talking about ;-).
Hagen
On 11/21/20 10:11 AM, Adrian Klaver wrot
On 11/21/20 8:47 AM, Adrian Klaver wrote:
On 11/21/20 8:20 AM, Adrian Klaver wrote:
On 11/21/20 8:00 AM, Hagen Finley wrote:
Hello,
Instead:
IF NEW.ndealid = OLD.ndealid AND NEW.revusd = OLD.revusd
AND NEW.stage = OLD.stage THEN
RETURN NULL; --Will cancel INSERT
ELSE
RET
On 11/21/20 8:20 AM, Adrian Klaver wrote:
On 11/21/20 8:00 AM, Hagen Finley wrote:
Hello,
Instead:
IF NEW.ndealid = OLD.ndealid AND NEW.revusd = OLD.revusd
AND NEW.stage = OLD.stage THEN
RETURN NULL; --Will cancel INSERT
ELSE
RETURN NEW;
END IF;
Well this is what happe
On 11/21/20 8:00 AM, Hagen Finley wrote:
Hello,
I am definitely out over my skis here so I’ll apologize in advance 😉.
Running version 12.5-1.pgdg20.04+1 on ubuntu. It’s essentially a
personal database I use to ingest sales forecast spreadsheets from which
I create custom reports for my job f
On Saturday, November 21, 2020, Hagen Finley wrote:
>
> I pull a new forecast spreadsheet each Monday. 80% of the records are the
> same as the existing records from the week before.
>
> Here’s what I (REALLY) want:
>
> Trigger looks at three fields prior to new insert: Deal ID (numeric),
> reven
Hello,
I am definitely out over my skis here so I’ll apologize in advance 😉.
Running version 12.5-1.pgdg20.04+1 on ubuntu. It’s essentially a
personal database I use to ingest sales forecast spreadsheets from which
I create custom reports for my job function.
I pull a new forecast spreadshe
On Sun, Nov 15, 2020 at 6:45 PM Adrian Klaver wrote:
> Database --> Table --> TOAST table.
Thanks, I was not sure about.
>
> > 2) while executing a query against toasted values I got this debug
> > message that I don't know what is meaning
>
> This happened when you where doing the REINDEX DATABA
On 2020-11-20 19:01:47 +0100, Durumdara wrote:
> We need to log the pg_dump's state.
> What objects are in copy, and what are the starting and ending times.
>
> But when I try to redirect the output, the result doesn't have timestamps.
>
> PG 11, on Windows.
>
> As I see the -v option isn't enou
TBH, it's also been a while since I needed to monitor pg_dump, since we now
use pgbackrest (which just so happens to have a progress meter...).
On 11/20/20 4:32 PM, Mark Johnson wrote:
This all sounds like a previous discussion on pg hackers about a progress
meter for pg_dump. Search the archi
14 matches
Mail list logo
