Re: Incorrect comment in fe-lobj.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Incorrect comment in fe-lobj.c
Date
Msg-id 19700.1346039272@sss.pgh.pa.us
Whole thread Raw
In response to Re: Incorrect comment in fe-lobj.c  (Tatsuo Ishii <ishii@postgresql.org>)
List pgsql-hackers
Tatsuo Ishii <ishii@postgresql.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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Why does analyze_new_cluster.sh use sleep?
Next
From: Bruce Momjian
Date:
Subject: Re: FATAL: bogus data in lock file "postmaster.pid": ""