Re: [HACKERS] Possible bug in parsing

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Hannu Krosing <hannu(at)trust(dot)ee>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Possible bug in parsing
Date: 1998-03-18 14:44:43
Message-ID: 350FDDDB.ACB3940@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > > I understand the 'there is more than one operator' errors, but
> > > what is so different between operators + and || ?
>
> Yes I know that, but why are they so different that I can have
> ARG1 op ARG2 op ARG3
> with + but not with ||

Ah! I *thought* that was a silly question, and as usual that's because I
didn't understand the question :)

They behave differently because the "+" operator is allowed to be
"left-associative", since its behavior is well-defined mathematically,
while the "||" operator falls into a broad class of multi-character
operators in the parser which are "non-associative". So, the parser does
not know whether to evaluate left-to-right or right-to-left and throws
an error instead.

> I actually found this while trying to find out how characters in
> strings are escaped and if \0 is supported in them.
>
> Is there some docs on escaping characters, and if not then where do
> you think it should go in docs ?

I believe that there are no docs on escaping characters and I would
suggest that docs for it should go into the user's guide in the section
on character data types (since it applies to all of them). That would be
in doc/src/sgml/datatype.sgml, probably in a "Sect2" at the end of the
"Sect1" on "Character Types" and just before the "Sect1" on "Date/Time
Types".

If you find it difficult to work with that source document, you can just
type the information and I can help to integrate it into the doc.

btw, I think that the escape conventions for strings need some work; the
fact that the characters are re-escaped when output makes it easy to do
a dump/reload but sort of defeats the usefulness of escaping anything in
the first place.

- Tom

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-03-18 15:09:30 Re: [HACKERS] Re: [QUESTIONS] MySQL benchmark page
Previous Message Michael Meskes 1998-03-18 12:56:58 another standards question