cosmetic patch to large object regression test

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

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