On 1/8/17 2:39 PM, Steve Singer wrote:
> The only concern I have with the functionality is that there isn't a way
> to change the type of a sequence.
If we implement the NEXT VALUE FOR expression (or anything similar that
returns a value from the sequence), then the return type of that
expression would be the type of the sequence. Then, changing the type
of the sequence would require reparsing all expressions involving the
sequence. This could probably be sorted out somehow, but I don't want
to be too lax now and cause problems for later features. There is a
similar case, namely changing the return type of a function, which we
also prohibit.
> @@ -1236,7 +1239,15 @@ init_params(ParseState *pstate, List *options,
> bool isInit,
> {
> DefElem *defel = (DefElem *) lfirst(option);
>
> - if (strcmp(defel->defname, "increment") == 0)
> + if (strcmp(defel->defname, "as") == 0)
> + {
> + if (as_type)
> + ereport(ERROR,
> + (errcode(ERRCODE_SYNTAX_ERROR),
> + errmsg("conflicting or
> redundant options")));
> + as_type = defel;
> + }
> + else if (strcmp(defel->defname, "increment") == 0)
>
> Should we including parser_errposition(pstate, defel->location))); like
> for the other errors below this?
Yes, good catch.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
