Allowing postgresql to accept 0xff syntax for data types that it makes sense for? - Mailing list pgsql-general

From Bill Moran
Subject Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
Date
Msg-id E33A47E1-8524-4EBE-A24A-25C8FBDC78B5@potentialtech.com
Whole thread Raw
Responses Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
I'm working on a project converting a bunch of code from another database
system to PostgreSQL.

One of the issues is that the previous system accepted integers and binary
data in the same hex format as C ... i.e. 0xff

I understand that the proper way to handle this in postgres is x'ff', but
the problem is that a large number of #define values use the 0xff syntax
and these macros are used both in C code, as well as in SQL. The simple
fact is that a LOT of code does this, and correcting it all and ensuring
that the modified code is correct is a BIG job. Just to clarify some of
the complexity: there is about 80,000 lines of PL/PGSQL code that contains
these macros, then is run through the C preprocessor to substitute actual
values for them before being loaded into Postgres.

Obviously, there are many options for fixing this. One of those options is
modifying PostgreSQL to accept the 0xff syntax ... and evaluating that
option is the reason for my post.

So, one of my questions is: does anyone have an existing simple answer on
how to fix this?

My other question: is there a specific reason why PostgreSQL doesn't support
this syntax, aside from "nobody has bothered to add such support"? Because
I'm considering writing a patch to Postgres and submitting it, but I'm not
going to go down that path if there's a specific reason why supporting this
syntax would be _bad_. Personally, I feel like it would be a good thing, as
it seems like a lot of other database systems support it, and even though
it's not ANSI, it's pretty much the de-facto standard.

--
Bill <wmoran@potentialtech.com>



pgsql-general by date:

Previous
From: Venkata Balaji N
Date:
Subject: Re: pg_xlog Concern
Next
From: Andomar
Date:
Subject: Replicate over pgbouncer?