"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> I think it is not really a weakness of the scheme, but a weakness that typmod
> is not available in some places where it would actually be needed.
> One effect of this is, that all the varlena datatypes have a redundant
> length info per r
> >> Hmm ... now that's an interesting thought. So the input converter would
> >> actively strip trailing blanks, output would add them back,
>
> > But how would the output know how many to put back?
>
> The output routine would need access to the column typmod. Which it
> would have, in simpl
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Hmm ... now that's an interesting thought. So the input converter would
>> actively strip trailing blanks, output would add them back,
> But how would the output know how many to put back?
The output routine would need access to
I said:
> "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> One alternate possible approach would maybe be to change the on-disk
>> representation to really be binary compatible and change the input
>> output and operator functions ?
> Seems like a great idea to me.
On further thought I
Tom Lane writes:
> Hmm ... now that's an interesting thought. So the input converter would
> actively strip trailing blanks, output would add them back,
But how would the output know how many to put back?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)--
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> One alternate possible approach would maybe be to change the on-disk
> representation to really be binary compatible and change the input
> output and operator functions ?
Hmm ... now that's an interesting thought. So the input converter
> I've gotten really tired of explaining to newbies why stuff involving
> char(n) fields doesn't work like they expect. Our current behavior is
> not valid per SQL92 anyway, I believe.
>
> I think there is a pretty simple solution now that we have pg_cast:
> we could stop treating char(n) as bin
I've gotten really tired of explaining to newbies why stuff involving
char(n) fields doesn't work like they expect. Our current behavior is
not valid per SQL92 anyway, I believe.
I think there is a pretty simple solution now that we have pg_cast:
we could stop treating char(n) as binary-equivalen
