Re: sequence data type

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Steve Singer <steve(at)ssinger(dot)info>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sequence data type
Date: 2017-01-09 20:03:56
Message-ID: e6c30aaa-9ae1-a807-5515-c4ecb8f0cb3f@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2017-01-09 20:14:19 Re: Add support to COMMENT ON CURRENT DATABASE
Previous Message Alvaro Herrera 2017-01-09 19:52:46 Re: Add support to COMMENT ON CURRENT DATABASE