> On Sun, 31 Oct 2004, Tatsuo Ishii wrote:
>
> > I don't understand your point. Today we already use one length()
> > function for any charsets as Tom has already pointed out.
>
> We have one length function that inside do different things depending on
> the charset. If you want to add a charset
> > I wonder what is the intention to allow such that syntax. It seems
> > it's just useless since we could make a function bar() which accepts
> > any charsets.
>
> One could override the behaviour of functions by adding a charset and a
> adding new definition of an old function name for that cha
On Sun, 31 Oct 2004, Tatsuo Ishii wrote:
> I don't understand your point. Today we already use one length()
> function for any charsets as Tom has already pointed out.
We have one length function that inside do different things depending on
the charset. If you want to add a charset and implement
On Sun, 31 Oct 2004, Tatsuo Ishii wrote:
> I wonder what is the intention to allow such that syntax. It seems
> it's just useless since we could make a function bar() which accepts
> any charsets.
One could override the behaviour of functions by adding a charset and a
adding new definition of an
> On Sun, 31 Oct 2004, Tatsuo Ishii wrote:
>
> > > and now we could add functions that work with this charset
> > >
> > > CREATE FUNCTION bar (x VARCHAR(255) CHARACTER SET foo)
> > >
> > > What we are saying is that we don't want to be able to do this?
> >
> > Not sure we want to add abo
On Sun, 31 Oct 2004, Tatsuo Ishii wrote:
> > and now we could add functions that work with this charset
> >
> > CREATE FUNCTION bar (x VARCHAR(255) CHARACTER SET foo)
> >
> > What we are saying is that we don't want to be able to do this?
>
> Not sure we want to add above. Is it somethin
> > For me that seems to be the right way. I'm not sure if two oids are
> > the right solution but we need to store extra info in varlena
> > structure to support charset/collation anyway. In my understanding
> > TOAST has already done in similar way.
> >
> > Other than charset/collation we also n
On Sun, 31 Oct 2004, Tatsuo Ishii wrote:
> > So you want to expand every string with 8 bytes (two oid's)?
>
> For me that seems to be the right way. I'm not sure if two oids are
> the right solution but we need to store extra info in varlena
> structure to support charset/collation anyway. In my
> On Sat, 30 Oct 2004, Tom Lane wrote:
>
> > > The alternative is storing the charset and collation inside each string.
> > > That seems like a too big price to pay, it belong in the type.
> >
> > No, the alternative you're proposing is too big a price to pay.
>
> So you want to expand every s
On Sat, 30 Oct 2004, Tom Lane wrote:
> > The alternative is storing the charset and collation inside each string.
> > That seems like a too big price to pay, it belong in the type.
>
> No, the alternative you're proposing is too big a price to pay.
So you want to expand every string with 8 byt
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Sat, 30 Oct 2004, Tom Lane wrote:
>> I'm worried about the fact that instead of, say, one length(text)
>> function, we would now have to have a different one for every
>> characterset/collation.
> For some functions one really want different ones d
On Sat, 30 Oct 2004, Tom Lane wrote:
> > Are you worried about performance or is it the smaller change that you
> > want?
>
> I'm worried about the fact that instead of, say, one length(text)
> function, we would now have to have a different one for every
> characterset/collation.
This is not ab
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Sat, 30 Oct 2004, Tom Lane wrote:
>> Why would we not keep this information right in the string values?
> We could, but then we would need to parse it every time.
Huh? We'd store it in the most compact pre-parsed form we could think
of; probably
On Sat, 30 Oct 2004, Tom Lane wrote:
> Why would we not keep this information right in the string values?
We could, but then we would need to parse it every time. Storing it in a
structured way seems like the database solution and at least as a user
from the client side it makes sense.
Are you
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> Today we store the max length of a string in the typmod field, but that
> has to be extended so we also store the charset and the collation of the
> string.
Why would we not keep this information right in the string values?
> [ unworkable proposal sn
I have a long term plan to implement charset support in pg and now when I
have dropped the work on the timestamps, I've been looking into this
subject.
Today we store the max length of a string in the typmod field, but that
has to be extended so we also store the charset and the collation of the
s
16 matches
Mail list logo
