Re: help with bison

From: Joe Conway <mail(at)joeconway(dot)com>
To: Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>
Cc: Barry Lind <barry(at)xythos(dot)com>, chriskl(at)familyhealth(dot)com(dot)au, pgsql-hackers(at)postgresql(dot)org
Subject: Re: help with bison
Date: 2002-04-11 16:26:19
Message-ID: 3CB5B92B.7090205@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Neil Conway wrote:
> On Wed, 10 Apr 2002 22:36:49 -0700 "Barry Lind" <barry(at)xythos(dot)com>
> wrote:
>
>> Neil,
>>
>> Will this allow you to pass bytea data as binary data in the
>> parameters section (ability to bind values to parameters) or will
>> this still require that the data be passed as a text string that
>> the parser needs to parse.
>
>
> The patch I'm working on would require that the parameters are still
> parsed, so it would likely suffer from the same performance
> problems.
>
> I'm unsure how to fix this without a change to the FE/BE protocol
> (and even then, it wouldn't be trivial). Suggestions?
>

The other day there was a discussion around the fact that X'ffff' will
get converted into an integer constant, e.g.

test=# select X'ffff';
?column?
----------
65535
(1 row)

, while SQL99 says that this syntax *should* be used to specify a
"binary string". It looks like the hex-to-integer magic actually occurs
in the lexer, and then the integer value of 65535 is passed to the
parser as an ICONST. I'm wondering if changing the lexer to make this a
conversion to a properly escaped bytea input string, and passing it to
the parser as a string constant would speed things up?

Joe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gavin Sherry 2002-04-11 16:26:47 Re: help with bison
Previous Message Bruce Momjian 2002-04-11 16:23:28 Re: RFC: Restructuring pg_aggregate