On Sun, Oct 31, 2010 at 6:13 PM, Peter Eisentraut wrote:
> On sön, 2010-10-31 at 14:30 -0400, Robert Haas wrote:
>> It's true that if the ostensible maximum length of a string or the
>> precision of a numeric get lost somewhere on their path through the
>> system, probably nothing terribly awful w
On sön, 2010-10-31 at 14:30 -0400, Robert Haas wrote:
> It's true that if the ostensible maximum length of a string or the
> precision of a numeric get lost somewhere on their path through the
> system, probably nothing terribly awful will happen. The worst case
> is that those values won't be enf
On sön, 2010-10-31 at 13:01 -0400, Tom Lane wrote:
> But I'm still wondering whether it's smart to try to promote all of
> this fundamentally-auxiliary information to first-class status. It's
> really unclear to me that that will end up being a net win either
> conceptually or notationally.
Fair
On sön, 2010-10-31 at 18:50 +0200, Heikki Linnakangas wrote:
> Yeah, that was my first impression too. I assumed that TypeInfo would be
> embedded in other structs directly, rather than a pointer and palloc.
> Something like:
>
> /*
> * TypeInfo - encapsulates type information
> */
> typedef
On sön, 2010-10-31 at 10:39 -0400, Tom Lane wrote:
> To my mind, the reason we have a distinction between type OID and
> typmod
> is that for most operations, you know the type OID of the result but
> not the typmod. Trying to force typmod into every API that currently
> works with type OIDs isn't
2010/10/31 Robert Haas :
> On Sun, Oct 31, 2010 at 1:01 PM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> ... I assumed that TypeInfo would be
>>> embedded in other structs directly, rather than a pointer and palloc.
>>
>> Yeah, that would avoid the extra-pallocs complaint, although it might
On Sun, Oct 31, 2010 at 1:01 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> ... I assumed that TypeInfo would be
>> embedded in other structs directly, rather than a pointer and palloc.
>
> Yeah, that would avoid the extra-pallocs complaint, although it might be
> notationally a bit of a PIT
Heikki Linnakangas writes:
> ... I assumed that TypeInfo would be
> embedded in other structs directly, rather than a pointer and palloc.
Yeah, that would avoid the extra-pallocs complaint, although it might be
notationally a bit of a PITA in places like equalfuncs.c. I think that
would end up
On 31.10.2010 16:39, Tom Lane wrote:
Peter Eisentraut writes:
Here's a big patch to avoid passing around type OID + typmod (+
collation) separately all over the place. Instead, there is a new
struct TypeInfo that contains these fields, and only a pointer is passed
around.
Some stuff in here
Peter Eisentraut writes:
> Here's a big patch to avoid passing around type OID + typmod (+
> collation) separately all over the place. Instead, there is a new
> struct TypeInfo that contains these fields, and only a pointer is passed
> around.
> Some stuff in here (or not in here) is probably a
10 matches
Mail list logo
