Re: Why not use the calloc to replace malloc?
On Sat, 22 Apr 2023, Tom Lane wrote: >Wen Yi writes: >> [ use calloc to replace zeroing fields individually ] […] >People have complained about this practice off-and-on, but no one has >provided any evidence that there's a significant performance cost. >The maintenance benefits are real though. Oh, interesting ;-) Thanks for this explanation. Another data point is: calloc is not correct for pointer fields, you have to manually assign NULL to them afterwards still, because NULL doesn’t have to be represented by all-zero bytes (e.g. TenDRA supports having 0x as NULL pointer as an option). bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Re: Why not use the calloc to replace malloc?
Thorsten Glaser writes: > On Sat, 22 Apr 2023, Tom Lane wrote: >> The maintenance benefits are real though. > Oh, interesting ;-) Thanks for this explanation. > Another data point is: calloc is not correct for pointer fields, > you have to manually assign NULL to them afterwards still, because > NULL doesn’t have to be represented by all-zero bytes (e.g. TenDRA > supports having 0x as NULL pointer as an option). Yeah, according to the letter of the C standard you shouldn't assume that NULL is physically the same as zero. We've blithely ignored that though --- there are lots of places that, for example, assume that palloc0() of an array of pointers will produce pointer values that are NULL. I don't see any real-world benefit in insisting on looping over such an array to set the pointers individually. But this is a good comparison point, because it illuminates one aspect of the maintenance argument. Suppose you want to add a field to struct Foo, and that field often or always needs to start out with a nonzero value. With our existing practice, grepping for places that assign to the adjacent fields will generally find all the places you need to touch. If we relied more on calloc or palloc0 to initialize fields, you'd have a harder time. People would be pushed into contorting their data representation choices so that fields could start out as physically zero, and that would lead to things like odd, inconsistent choices of boolean flag polarity. regards, tom lane
Replicating / Updating Materialized views across databases
Hi, I have large centralized master database for which I created a few materialized views exclusively used by Web sites running in different regions on their own servers. To avoid having to connect to and pull data from across the globe I am thinking about running small postgres instances in each region that only hold these materialized views. (trying to avoid Memcached, Redis) Is there a way to refresh a materialized view across servers? Maybe using DB Link? What would be the most efficient way to keep these in sync? Any suggestions? Would appreciate your thoughts on this. Thanks Alex
alter table rename column can event trigger capture new column name
hi. alter table t1 rename col1 to id. Is it possible to use an event trigger to capture the new column name "id"?
Re: alter table rename column can event trigger capture new column name
On Mon, Apr 24, 2023 at 10:46 AM jian he wrote: > > hi. > alter table t1 rename col1 to id. > > Is it possible to use an event trigger to capture the new column name > "id"? > > > sorry for the noise. I figured it out. substring(_object_identity FROM (LENGTH(_object_identity) + 2 - STRPOS(REVERSE(_object_identity), '.')))
