From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Aggregates with context - a question |
Date: | 1999-06-10 23:27:39 |
Message-ID: | 11233.929057259@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Philip Warner <pjw(at)rhyme(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 1999-06-10 23:46:17 | RE: [HACKERS] 6.5 Release date |
Previous Message | Bruce Momjian | 1999-06-10 22:58:22 | Re: [PORTS] Patch for m68k architecture |