From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Incorrect comment in fe-lobj.c |
Date: | 2012-08-27 01:57:14 |
Message-ID: | 20120827.105714.1804263967623560660.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
>> I found following in fe-lobj.c:
>
>> * currently, only L_SET is a legal value for whence
>
>> I don't know where "L_SET" comes from.
>
> Hmm, seems to be that way in the original commit to our CVS (Postgres95).
> I don't find this code at all in Postgres v4r2 though.
I just remembered that "L_SET" came from old BSDish systems.
>> Anyway this should be:
>> * whence must be one of SEEK_SET, SEEK_CUR or SEEK_END.
>
> 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. */
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. */
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2012-08-27 01:58:44 | Re: 64-bit API for large object |
Previous Message | Tom Lane | 2012-08-27 01:42:49 | Re: Incorrect comment in fe-lobj.c |