[HACKERS] A weird bit in pg_upgrade/exec.c - Mailing list pgsql-hackers

From a.akenteva@postgrespro.ru
Subject [HACKERS] A weird bit in pg_upgrade/exec.c
Date
Msg-id f9266a85d918a3cf3a386b5148aee666@postgrespro.ru
Whole thread Raw
Responses Re: [HACKERS] A weird bit in pg_upgrade/exec.c  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: [HACKERS] A weird bit in pg_upgrade/exec.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hello!
I've came across a weird bit in pg_upgrade/exec.c

We have a function check_bin_dir() which goes like this (old_cluster and 
new_cluster are global variables):
void check_bin_dir(ClusterInfo *cluster)
{    ...    get_bin_version(&old_cluster);    get_bin_version(&new_cluster);    ...
}

This function has two calls:
check_bin_dir(&old_cluster);
check_bin_dir(&new_cluster);

I'd like to substitute these last two lines with this:
get_bin_version(cluster);

Doing it would simplify the patch I'm writing, but I'm worried I might 
break something that's been there for a long time and has been working 
fine. Is there maybe a reason for it to be this way that I don't happen 
to understand?
Also, there's the exact same situation with the get_bin_version() 
function in the same file.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: [HACKERS] Reorder header files in alphabetical order
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager