[BUGS] BUG #8176: problem with the ALTER TYPE name RENAME TO new_name [ CASCADE | RESTRICT ] syntax
The following bug has been logged on the website: Bug reference: 8176 Logged by: Maksym Boguk Email address: maxim.bo...@gmail.com PostgreSQL version: 9.2.4 Operating system: Any Description: Hi, It seems that documentation wrong or [ CASCADE | RESTRICT ] feature of ALTER TYPE ... RENAME TO isn't implemented. Test case: create type test as (qqq integer); CREATE TYPE alter type test rename to test1 RESTRICT; ERROR: syntax error at or near RESTRICT LINE 1: alter type test rename to test1 RESTRICT; ^ alter type test rename to test1 CASCADE; ERROR: syntax error at or near CASCADE LINE 1: alter type test rename to test1 CASCADE; ^ However: [local]:5432 postgres@postgres=# alter type test rename to test1; ALTER TYPE -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] COPY .... (FORMAT binary) syntax doesn't work
On 26 May 2013 16:35, Heikki Linnakangas hlinnakan...@vmware.com wrote:
My attempts to fix that look pretty ugly, so I'm not even going to
post them. I can stop the error on binary by causing errors on csv and
text, obviously not a fix. Any grammar based fix looks like it would
restrict the list of formats, which breaks the orginal intention of
the syntax change.
This seems to work:
This was almost exactly the fix I described above that only fixes that
specific case and then breaks others.
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -2528,3 +2528,7 @@ copy_generic_opt_elem:
{
$$ = makeDefElem($1, $2);
}
+ | ColLabel BINARY
+ {
+ $$ = makeDefElem($1, (Node *)
makeString(binary));
+ }
So, no that doesn't work.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [HACKERS] [BUGS] COPY .... (FORMAT binary) syntax doesn't work
On 26 May 2013 17:10, Tom Lane t...@sss.pgh.pa.us wrote: Heikki Linnakangas hlinnakan...@vmware.com writes: More readable would be to invent an intermediate nonterminal falling between ColId and ColLabel, whose expansion would be IDENT | unreserved_keyword | col_name_keyword | type_func_name_keyword, and then replace ColId_or_Sconst with whatever-we-call-that_or_Sconst. Any thoughts about a name for that new nonterminal? Do you think complicating the parser in that way is worth the trouble for this case? Could that slow down parsing? We don't actually have to fix it; clearly not too many people are bothered, since no complaints in 3 years. Documenting 'binary' seems better. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8176: problem with the ALTER TYPE name RENAME TO new_name [ CASCADE | RESTRICT ] syntax
Maxim, * maxim.bo...@gmail.com (maxim.bo...@gmail.com) wrote: It seems that documentation wrong or [ CASCADE | RESTRICT ] feature of ALTER TYPE ... RENAME TO isn't implemented. Actually, I'm pretty sure it's implemented but the grammar for it was broken during refactoring to have all the ALTER .. RENAME operations go through the same code paths. Test case: Thanks for this. I'm working on fixing this and will also add regression tests to, hopefully, avoid this getting broken in the future. Thanks again, Stephen signature.asc Description: Digital signature
Re: [BUGS] BUG #8176: problem with the ALTER TYPE name RENAME TO new_name [ CASCADE | RESTRICT ] syntax
Stephen Frost sfr...@snowman.net writes: * maxim.bo...@gmail.com (maxim.bo...@gmail.com) wrote: It seems that documentation wrong or [ CASCADE | RESTRICT ] feature of ALTER TYPE ... RENAME TO isn't implemented. Actually, I'm pretty sure it's implemented but the grammar for it was broken during refactoring to have all the ALTER .. RENAME operations go through the same code paths. Are we sure the documentation's not wrong? A quick test says this syntax isn't accepted in *any* existing release, and I can't say I understand what it should do anyway. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8176: problem with the ALTER TYPE name RENAME TO new_name [ CASCADE | RESTRICT ] syntax
Maxim, * Stephen Frost (sfr...@snowman.net) wrote: * maxim.bo...@gmail.com (maxim.bo...@gmail.com) wrote: It seems that documentation wrong or [ CASCADE | RESTRICT ] feature of ALTER TYPE ... RENAME TO isn't implemented. Actually, I'm pretty sure it's implemented but the grammar for it was broken during refactoring to have all the ALTER .. RENAME operations go through the same code paths. Nope, I was wrong- this looks to be a documentation bug, actually. The documentation should be: ALTER TYPE name RENAME ATTRIBUTE attribute_name TO new_attribute_name [ CASCADE | RESTRICT ] ALTER TYPE name RENAME TO new_name Which makes more sense (to me at least) anyway. Do you have a need for this version: ALTER TYPE name RENAME TO new_name [ CASCADE | RESTRICT ] or were you just playing with things..? Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] BUG #8176: problem with the ALTER TYPE name RENAME TO new_name [ CASCADE | RESTRICT ] syntax
* Tom Lane (t...@sss.pgh.pa.us) wrote: Are we sure the documentation's not wrong? A quick test says this syntax isn't accepted in *any* existing release, and I can't say I understand what it should do anyway. Was just composing an email to that effect, actually. I agree that it's a documentation issue. Of course, that makes it easier to fix. :) Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [BUGS] COPY .... (FORMAT binary) syntax doesn't work
Simon Riggs si...@2ndquadrant.com writes: On 26 May 2013 17:10, Tom Lane t...@sss.pgh.pa.us wrote: More readable would be to invent an intermediate nonterminal falling between ColId and ColLabel, whose expansion would be IDENT | unreserved_keyword | col_name_keyword | type_func_name_keyword, and then replace ColId_or_Sconst with whatever-we-call-that_or_Sconst. Any thoughts about a name for that new nonterminal? Do you think complicating the parser in that way is worth the trouble for this case? Could that slow down parsing? It makes the grammar tables a bit larger (1% or so IIRC). There would be some distributed penalty for that, but probably not much. Of course there's always the slippery-slope argument about that. We don't actually have to fix it; clearly not too many people are bothered, since no complaints in 3 years. Documenting 'binary' seems better. Well, my thought is there are other cases. For instance: regression=# create role binary; ERROR: syntax error at or near binary LINE 1: create role binary; ^ regression=# create user cross; ERROR: syntax error at or near cross LINE 1: create user cross; ^ If we don't have to treat type_func_name_keywords as reserved in these situations, shouldn't we avoid doing so? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8176: problem with the ALTER TYPE name RENAME TO new_name [ CASCADE | RESTRICT ] syntax
Maxim, * maxim.bo...@gmail.com (maxim.bo...@gmail.com) wrote: It seems that documentation wrong or [ CASCADE | RESTRICT ] feature of ALTER TYPE ... RENAME TO isn't implemented. I've updated the documentation to reflect that [ CASCADE | RESTRICT ] is supported for ALTER TYPE .. RENAME ATTRIBUTE and that it isn't supported for ALTER TYPE .. RENAME TO. This update will be pushed out with the next releases. Thanks! Stephen signature.asc Description: Digital signature
[BUGS] BUG #8177: initscript should create /var/run/postgresql
The following bug has been logged on the website: Bug reference: 8177 Logged by: stronny Email address: stro...@celestia.ru PostgreSQL version: 9.2.4 Operating system: wheezy Description: When installed from apt.postgresql.org Postgres fails to start on system boot. Wheezy changed /var/run to become memory-based so initscript should create /var/run/postgresql if necessary. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
