On Fri, Sep 22, 2000 at 12:26:45PM -0400, Tom Lane wrote:
> Marko Kreen <marko(at)l-t(dot)ee> writes:
> > 1) Precedence. I quite nonscientifically hacked in gram.y,
> > and could not still make it understand expression '5 # ~1'
> > nor the precedence between '&' and '|#'...
> > At the moment all the gram.y changes could be dropped and
> > it works ok, but without operator precedence. Any hints?
> What you missed is that there's a close coupling between gram.y and
> scan.l. There are certain single-character operators that are returned
> as individual-character tokens by scan.l, and these are exactly the ones
> that gram.y wants to treat specially. All else are folded into the
> generic token "Op". You'd need to twiddle the character type lists in
> scan.l if you want to treat '~' '&' or '#' specially in gram.y.
> However, I'm pretty dubious of the idea of changing the precedence
> assigned to these operator names, because there's a real strong risk
> of breaking existing applications if you do that --- worse, of breaking
> them in a subtle, hard-to-detect way. Even though I think '|' is
> clearly given a bogus precedence, I doubt it's a good idea to change it.
I guess I better drop it then...
One idea I had while looking at gram.y is that the precedence
should somehow based on context e.g. depending on what datatypes
operator is used. Escpecially because one symbol has different
meaning based on data. Heh, but this would be complex...
> > 3) Choice of operators. As I understand the '^' is taken,
> > I wont get it. Now, in gram.y I found that the '|' is
> > used in weird situations and with weird precedence so
> > maybe I should use something else for OR too?
> Well, you *could* use '^' since there's no definition of it for integer
> operands. But that would mean that something like '4^2', which was
> formerly implicitly coerced to float and interpreted as floating
> power function, would suddenly mean something different. Again a
> serious risk of silently breaking applications. This doesn't apply to
> '|' though, since it has no numeric interpretation at all right now.
I am afraid of '^'. Also as the 'power' precedence would be used
it would be very un-intuitive, no-precedence is better. OTOH the
bit-string stuff uses '^' (with its precedence) so it would be nice
to be similar?
> > 4) Is anybody else interested? ;)
> Dunno. I think the bitstring datatype is probably a better choice,
> since it's standard and this feature is not.
I looked at it and did not liked it. If it is from some standard
then its nice to PostgreSQL to support it, but somehow I guess
that the binary ops on int's would be used more than the bit-string
stuff. Mostly because its something familiar from other languages.
But maybe its just me...
I'll send a revised diff shortly
In response to
pgsql-hackers by date
|Next:||From: Brook Milligan||Date: 2000-09-23 15:49:50|
|Subject: Re: type design guidance needed|
|Previous:||From: Tom Lane||Date: 2000-09-23 05:41:22|
|Subject: Re: type design guidance needed |