Skip site navigation (1) Skip section navigation (2)

Re: pgsql crollable cursor doesn't support one form of postgresql's cu

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)hotmail(dot)com>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgsql crollable cursor doesn't support one form of postgresql's cu
Date: 2007-04-27 02:45:49
Message-ID: 200704270245.l3R2jnt04457@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Your patch has been added to the PostgreSQL unapplied patches list at:

	http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------


Pavel Stehule wrote:
> >
> >"Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com> writes:
> > > I found one unsupported form plpgsql's fetch statement which is  
> >supported
> > > by postgresql.
> >
> > > PostgreSQL knows
> > > FETCH 3 FROM ....
> >
> > > but plpgsql needs everytime direction's keyword.
> >
> >No, I think that's OK, because that form specifies fetching 3 rows,
> >which plpgsql's FETCH doesn't support.
> >
> 
> it's true. There is same question for move statement too. Other difference 
> is unsupported keyword IN.
> 
> It can be fixed:
> 
> *** ./gram.y.orig	2007-04-19 20:27:17.000000000 +0200
> --- ./gram.y	2007-04-19 20:41:16.000000000 +0200
> ***************
> *** 2059,2071 ****
>   	else if (pg_strcasecmp(yytext, "absolute") == 0)
>   	{
>   		fetch->direction = FETCH_ABSOLUTE;
> ! 		fetch->expr = plpgsql_read_expression(K_FROM, "FROM");
>   		check_FROM = false;
>   	}
>   	else if (pg_strcasecmp(yytext, "relative") == 0)
>   	{
>   		fetch->direction = FETCH_RELATIVE;
> ! 		fetch->expr = plpgsql_read_expression(K_FROM, "FROM");
>   		check_FROM = false;
>   	}
>   	else if (pg_strcasecmp(yytext, "forward") == 0)
> --- 2059,2071 ----
>   	else if (pg_strcasecmp(yytext, "absolute") == 0)
>   	{
>   		fetch->direction = FETCH_ABSOLUTE;
> ! 		fetch->expr = read_sql_construct(K_FROM, K_IN, "FROM/IN", "SELECT ", 
> true, true, NULL);
>   		check_FROM = false;
>   	}
>   	else if (pg_strcasecmp(yytext, "relative") == 0)
>   	{
>   		fetch->direction = FETCH_RELATIVE;
> ! 		fetch->expr = read_sql_construct(K_FROM, K_IN, "FROM/IN", "SELECT ", 
> true, true, NULL);
>   		check_FROM = false;
>   	}
>   	else if (pg_strcasecmp(yytext, "forward") == 0)
> ***************
> *** 2076,2081 ****
> --- 2076,2087 ----
>   	{
>   		fetch->direction = FETCH_BACKWARD;
>   	}
> + 	else if (tok != T_SCALAR)
> + 	{
> + 		plpgsql_push_back_token(tok);
> + 		fetch->expr = read_sql_construct(K_FROM, K_IN, "FROM/IN", "SELECT ", 
> true, true, NULL);
> + 		check_FROM = false;
> + 	}
>   	else
>   	{
>   		/* Assume there's no direction clause */
> ***************
> *** 2083,2091 ****
>   		check_FROM = false;
>   	}
> 
> ! 	/* check FROM keyword after direction's specification */
> ! 	if (check_FROM && yylex() != K_FROM)
> ! 		yyerror("expected \"FROM\"");
> 
>   	return fetch;
>   }
> --- 2089,2097 ----
>   		check_FROM = false;
>   	}
> 
> ! 	/* check FROM or IN keyword after direction's specification */
> ! 	if (check_FROM && (yylex() != K_FROM && yylex() != K_IN))
> ! 		yyerror("expected \"FROM/IN\"");
> 
>   	return fetch;
>   }
> 
> Regards
> Pavel Stehule
> 
> _________________________________________________________________
> Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>        message can get through to the mailing list cleanly

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2007-04-27 02:47:20
Subject: Re: [COMMITTERS] pgsql: Remove some of the most blatant brain-fade in the recent guc
Previous:From: Bruce MomjianDate: 2007-04-27 02:43:08
Subject: Re: elog(FATAL) vs shared memory

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group