Re: C function question - Mailing list pgsql-general

From Merlin Moncure
Subject Re: C function question
Date
Msg-id b42b73150902040614vcd3c2e0j321ee3de79f7ba32@mail.gmail.com
Whole thread Raw
In response to Re: C function question  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Tue, Feb 3, 2009 at 6:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Tue, Feb 3, 2009 at 4:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> You know, maybe we should stop holding our noses and do something about
>>> this old gotcha.  That type's not going away anytime soon, but could we
>>> rename it to char1 or something like that?  (With some sort of backward
>>> compatibility hack, like a domain named "char".)
>
>> domains are out, unless arrays of domains are addressed first.
>
> [ raised eyebrow... ]  You've got apps that depend on array of "char"?

yes.  For example. I wrote a ISAM emulation wrapper for libpq a few
years back that supported some cobol applicaitons.  char(1) fields are
common cobol (and were mapped to "char" for performance), as are
arrays of records.  since at the time there was no support for arrays
of composites or domains, I had to use parallel arrays of POD types
when mapping these types of records to PostgreSQL. This would now
break.

Anyways, why prefer domain to type alias (char1 : "char" :: bigint :
int8)?  Main advantage of domains is being able to add user level
constraints, which is kinda weird for system provided type.

merlin

pgsql-general by date:

Previous
From: Richard Huxton
Date:
Subject: Re: Crash of Postgresql on Windows
Next
From: "Raymond C. Rodgers"
Date:
Subject: Re: field with Password