From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Incorrect comment in fe-lobj.c |
Date: | 2012-08-27 03:47:52 |
Message-ID: | 19700.1346039272@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
>> Agreed. But looking at this brings a thought to mind: our code is
>> assuming that SEEK_SET, SEEK_CUR, SEEK_END have identical values on the
>> client and server. The lack of complaints over the past fifteen years
>> suggests that every Unix-oid platform is in fact using the same values
>> for these macros ... but that seems kind of a risky assumption. Is it
>> worth changing? And if so, how would we go about that?
> I personaly have not seen any definitions other than below before.
> # define SEEK_SET 0 /* Seek from beginning of file. */
> # define SEEK_CUR 1 /* Seek from current position. */
> # define SEEK_END 2 /* Seek from end of file. */
Same here.
> However I agree your point. What about defining our own definitions
> which have exact same values as above? i.e.;
> # define PG_SEEK_SET 0 /* Seek from beginning of file. */
> # define PG_SEEK_CUR 1 /* Seek from current position. */
> # define PG_SEEK_END 2 /* Seek from end of file. */
Well, the thing is: if all platforms use those same values, then this is
a pretty useless change (and yet one that affects client applications,
not only our own code). If not all platforms use those values, then
this is a wire-protocol break for those that don't.
Is there a way to fix things so that we don't have a protocol break?
I think it's clearly impossible across platforms that have inconsistent
SEEK_XXX definitions; but such cases were incompatible before anyway.
Can we make it not break if client and server are the same platform,
but have some other set of SEEK_XXX values?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-08-27 04:02:13 | Re: FATAL: bogus data in lock file "postmaster.pid": "" |
Previous Message | Bruce Momjian | 2012-08-27 03:23:09 | Re: Why does analyze_new_cluster.sh use sleep? |