Philip Warner <pjw@rhyme.com.au> writes:
> At 10:20 9/06/99 -0400, Tom Lane wrote:
>> ... There has been some talk of inventing a type OID
>> representing "C string", and that (when available) might be a better way
>> of declaring transtype1 when it's really a private struct of some sort.
> Sounds like a wonderful idea; does this mean that users can be
> prevented from declaring a column of type 'C String'? Or do you then
> need to build all the support functions?
The original proposal was to have a type OID that would represent the
textual input or output of datatype input/output functions, in order to
solve the problems we have now with not being able to typecheck explicit
uses of these functions. There would be no reason to make it a "real"
type that could be declared as a column type, AFAICS. You'd have to be
able to refer to it by name in order to declare user-supplied datatype
I/O functions, however. Might take a bit of a kluge to make the type
acceptable for one purpose and not the other...
> I suppose the alternative
> would be to use a 'varbinary' (or varchar?), which has the first word
> being the structure length. That would at least be standard.
That's actually probably a better idea; I'd suggest the existing "bytea"
type could be used to represent the workspace datatype for aggregates
that are really using a private struct. Not sure how you'd get it
initialized at aggregate startup, but that's probably doable.
regards, tom lane