Hello!
Peter J. Holzer ezt írta (időpont: 2022. máj. 11., Sze,
0:44):
> On 2022-05-07 15:02:09 +0200, Durumdara wrote:
>
> > So in the new trigger we can't load them all with:
>
> How do you get a new trigger on one table but not the new columns on the
> other table? Wouldn't you update both at
On Sat, May 07, 2022 at 07:41:44AM -0700, David G. Johnston wrote:
> No. I’d probably approach this by generically converting the NEW record to
> json and working with that. Non-existent object keys return null when
> accessed.
One note - in my tests working with hstore was significantly faster
On 2022-05-07 15:02:09 +0200, Durumdara wrote:
> We stored the username in a temporary table which was created by the client
> app.
> With this technique we can log these names in triggers too.
>
> Now we extend it with user id and later the comp name.
>
> Because we can update the client applica
Dear David!
That was a very good idea! I have integrated it! :-)
Priorly I had another idea: I made a DDL to extend the table with "add
column if not exists" elements.
But what you suggested is better. Thank you!
Best wishes
dd
David G. Johnston ezt írta (időpont: 2022.
máj. 7., Szo, 16:41):
On Saturday, May 7, 2022, Durumdara wrote:
>
>
> So is there any syntax to not fall on missing columns?
>
No. I’d probably approach this by generically converting the NEW record to
json and working with that. Non-existent object keys return null when
accessed.
David J.
Hello!
We stored the username in a temporary table which was created by the client
app.
With this technique we can log these names in triggers too.
Now we extend it with user id and later the comp name.
Because we can update the client applications slowly, some client's tables
have these one or