Thread: cosmetic patch to large object regression test
Since I have now learned that it is possible to input values in hex in postgres, I submit this patch to clean up the ugly workaround I did in the largeobject regression test to try to input hex values. It does not change the functionality of the test at all, it just makes it more readable. In detail, before when I needed to write hex values, for example 0x20000 | 0x40000, for the flags to lo_open, I would write it: CAST((2 | 4) * 16^4 AS integer) Now, I write it: CAST(x'20000' | x'40000' AS integer) which is more like the C and other language consumers of the API, and also is more obvious what I am trying to do, IMHO. -- Real Programs don't use shared text. Otherwise, how can they use functions for scratch space after they are finished calling them?
Attachment
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---------------------------------------------------------------------------
Jeremy Drake wrote:
> Since I have now learned that it is possible to input values in hex in
> postgres, I submit this patch to clean up the ugly workaround I did in the
> largeobject regression test to try to input hex values. It does not
> change the functionality of the test at all, it just makes it more
> readable.
>
> In detail, before when I needed to write hex values, for example
> 0x20000 | 0x40000,
> for the flags to lo_open, I would write it:
> CAST((2 | 4) * 16^4 AS integer)
>
> Now, I write it:
> CAST(x'20000' | x'40000' AS integer)
>
> which is more like the C and other language consumers of the API, and also
> is more obvious what I am trying to do, IMHO.
>
>
> --
> Real Programs don't use shared text. Otherwise, how can they use
> functions for scratch space after they are finished calling them?
Content-Description:
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Patch applied. Thanks. --------------------------------------------------------------------------- Jeremy Drake wrote: > Since I have now learned that it is possible to input values in hex in > postgres, I submit this patch to clean up the ugly workaround I did in the > largeobject regression test to try to input hex values. It does not > change the functionality of the test at all, it just makes it more > readable. > > In detail, before when I needed to write hex values, for example > 0x20000 | 0x40000, > for the flags to lo_open, I would write it: > CAST((2 | 4) * 16^4 AS integer) > > Now, I write it: > CAST(x'20000' | x'40000' AS integer) > > which is more like the C and other language consumers of the API, and also > is more obvious what I am trying to do, IMHO. > > > -- > Real Programs don't use shared text. Otherwise, how can they use > functions for scratch space after they are finished calling them? Content-Description: [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Sat, 3 Mar 2007, Bruce Momjian wrote: > > Patch applied. Thanks. Another usage of the old workaround for the flags was added with the application of the lo_truncate patch. This patch changes that one to be consistent with the others. > --------------------------------------------------------------------------- > > > Jeremy Drake wrote: > > Since I have now learned that it is possible to input values in hex in > > postgres, I submit this patch to clean up the ugly workaround I did in the > > largeobject regression test to try to input hex values. It does not > > change the functionality of the test at all, it just makes it more > > readable. > > > > In detail, before when I needed to write hex values, for example > > 0x20000 | 0x40000, > > for the flags to lo_open, I would write it: > > CAST((2 | 4) * 16^4 AS integer) > > > > Now, I write it: > > CAST(x'20000' | x'40000' AS integer) > > > > which is more like the C and other language consumers of the API, and also > > is more obvious what I am trying to do, IMHO. > > > > > > -- > > Real Programs don't use shared text. Otherwise, how can they use > > functions for scratch space after they are finished calling them? > Content-Description: > > [ Attachment, skipping... ] > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 3: Have you checked our extensive FAQ? > > > > http://www.postgresql.org/docs/faq > > -- One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. -- Robert Firth
Attachment
On Sat, 2007-03-03 at 14:48 -0800, Jeremy Drake wrote: > Another usage of the old workaround for the flags was added with the > application of the lo_truncate patch. This patch changes that one to be > consistent with the others. Applied, thanks. -Neil