Re: [HACKERS] is syntax columname(tablename) necessary still?
On Mon, Aug 09, 2010 at 12:18:33PM +0200, Pavel Stehule wrote: Hello I am working on Grouping Sets support. The first issue is cube keyword. Contrib module cube define a few functions cube. So if we want to continue in support this function, then cube have to be a unreserved keyword. The cube contrib module was only ever meant to be replaced by the real feature, which you're working on, so +1 for dropping everything in it that you are not replacing with the one which complies with the SQL standard. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is syntax columname(tablename) necessary still?
On Mon, Aug 9, 2010 at 2:02 PM, David Fetter da...@fetter.org wrote: I am working on Grouping Sets support. The first issue is cube keyword. Contrib module cube define a few functions cube. So if we want to continue in support this function, then cube have to be a unreserved keyword. The cube contrib module was only ever meant to be replaced by the real feature, which you're working on, so +1 for dropping everything in it that you are not replacing with the one which complies with the SQL standard. That's not right. The cube contrib module is a kind of vector data type. It's not related in any way to the SQL CUBE or ROLLUP syntax. Personally I think cube is uncommonly used and CUBE an important enough SQL feature that we should just bite the bullet and kill/rename the contrib module. Partly that's because I find the name quite strange and non-intuitive anyways. Something like vector or ntuple would be far clearer. Doing nasty hacks to make CUBE a non-reserved word doesn't seem justified by the contrib module. Now conceivably it's a word users might be using in their schema and that might be a good enough reason to hack up the grammar -- but it's not like it's a new keyword in SQL so it shouldn't come as a surprise to users when they get an error. I think more people are surprised when we *don't* support CUBE than will be when we start doing so. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is syntax columname(tablename) necessary still?
On Mon, Aug 09, 2010 at 02:23:55PM +0100, Greg Stark wrote: On Mon, Aug 9, 2010 at 2:02 PM, David Fetter da...@fetter.org wrote: I am working on Grouping Sets support. The first issue is cube keyword. Contrib module cube define a few functions cube. So if we want to continue in support this function, then cube have to be a unreserved keyword. The cube contrib module was only ever meant to be replaced by the real feature, which you're working on, so +1 for dropping everything in it that you are not replacing with the one which complies with the SQL standard. That's not right. That's what I get for posting before coffee :P +1 for renaming the stuff in the contrib/cube module, along with a loud warning about this in the release notes, release announcement, etc. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is syntax columname(tablename) necessary still?
2010/8/9 Greg Stark gsst...@mit.edu: On Mon, Aug 9, 2010 at 2:02 PM, David Fetter da...@fetter.org wrote: I am working on Grouping Sets support. The first issue is cube keyword. Contrib module cube define a few functions cube. So if we want to continue in support this function, then cube have to be a unreserved keyword. The cube contrib module was only ever meant to be replaced by the real feature, which you're working on, so +1 for dropping everything in it that you are not replacing with the one which complies with the SQL standard. That's not right. The cube contrib module is a kind of vector data type. It's not related in any way to the SQL CUBE or ROLLUP syntax. Personally I think cube is uncommonly used and CUBE an important enough SQL feature that we should just bite the bullet and kill/rename the contrib module. Partly that's because I find the name quite strange and non-intuitive anyways. Something like vector or ntuple would be far clearer. Doing nasty hacks to make CUBE a non-reserved word doesn't seem justified by the contrib module. Now conceivably it's a word users might be using in their schema and that might be a good enough reason to hack up the grammar -- but it's not like it's a new keyword in SQL so it shouldn't come as a surprise to users when they get an error. I think more people are surprised when we *don't* support CUBE than will be when we start doing so. ok - with reserved keyword the life is little bit nicer, but still if we remove obsolete columnname(tablename) syntax, we can remeve a few hack in parser - and implement a GROUPING SETS grammar little bit cleaner. Pavel -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is syntax columname(tablename) necessary still?
Greg Stark gsst...@mit.edu writes: Personally I think cube is uncommonly used and CUBE an important enough SQL feature that we should just bite the bullet and kill/rename the contrib module. Yeah. It looks to me like CUBE will have to be a type_function_name keyword (but hopefully not fully reserved), which will mean that we can't have a contrib module defining a type by that name. Ergo, rename. ... Now conceivably it's a word users might be using in their schema and that might be a good enough reason to hack up the grammar -- but it's not like it's a new keyword in SQL so it shouldn't come as a surprise to users when they get an error. As long as we can avoid making it fully reserved, tables/columns named cube will still work, so the damage should be limited. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is syntax columname(tablename) necessary still?
Pavel Stehule pavel.steh...@gmail.com writes: I am working on Grouping Sets support. The first issue is cube keyword. Contrib module cube define a few functions cube. So if we want to continue in support this function, then cube have to be a unreserved keyword. But then we have a gram conflict with mentioned obsolete syntax. I am thinking so after removing add_missing_from this syntax is useless. Without this feature we can clean a gramatic. That's a documented and useful feature. It's not going away. Even if it did go away, removing it wouldn't do a thing to solve grammar problems, because the grammar isn't involved in that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is syntax columname(tablename) necessary still?
2010/8/9 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: I am working on Grouping Sets support. The first issue is cube keyword. Contrib module cube define a few functions cube. So if we want to continue in support this function, then cube have to be a unreserved keyword. But then we have a gram conflict with mentioned obsolete syntax. I am thinking so after removing add_missing_from this syntax is useless. Without this feature we can clean a gramatic. That's a documented and useful feature. It's not going away. Even if it did go away, removing it wouldn't do a thing to solve grammar problems, because the grammar isn't involved in that. This isn't a SQL feature and it coming from old times like missing from. Without this we can little bit simplify ParseFuncOrColumn. But I don't know, if this can be a significant win. It is just obsolete. Regards Pavel regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is syntax columname(tablename) necessary still?
On Mon, Aug 9, 2010 at 10:45 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2010/8/9 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: I am working on Grouping Sets support. The first issue is cube keyword. Contrib module cube define a few functions cube. So if we want to continue in support this function, then cube have to be a unreserved keyword. But then we have a gram conflict with mentioned obsolete syntax. I am thinking so after removing add_missing_from this syntax is useless. Without this feature we can clean a gramatic. That's a documented and useful feature. It's not going away. Even if it did go away, removing it wouldn't do a thing to solve grammar problems, because the grammar isn't involved in that. This isn't a SQL feature and it coming from old times like missing from. Without this we can little bit simplify ParseFuncOrColumn. But I don't know, if this can be a significant win. It is just obsolete. I think the point is that it's not going to solve the problem you have right now. It might or might not be a good thing to do, but it's not going to help with GROUPING SETS. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is syntax columname(tablename) necessary still?
2010/8/9 Tom Lane t...@sss.pgh.pa.us: Greg Stark gsst...@mit.edu writes: Personally I think cube is uncommonly used and CUBE an important enough SQL feature that we should just bite the bullet and kill/rename the contrib module. Yeah. It looks to me like CUBE will have to be a type_function_name keyword (but hopefully not fully reserved), which will mean that we can't have a contrib module defining a type by that name. Ergo, rename. I am afraid, CUBE and ROLLUP have to be a reserved keyword because as type_function_name is in conflict with func_name ( ... Regards Pavel Stehule ... Now conceivably it's a word users might be using in their schema and that might be a good enough reason to hack up the grammar -- but it's not like it's a new keyword in SQL so it shouldn't come as a surprise to users when they get an error. As long as we can avoid making it fully reserved, tables/columns named cube will still work, so the damage should be limited. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is syntax columname(tablename) necessary still?
On Mon, Aug 9, 2010 at 11:06 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2010/8/9 Tom Lane t...@sss.pgh.pa.us: Greg Stark gsst...@mit.edu writes: Personally I think cube is uncommonly used and CUBE an important enough SQL feature that we should just bite the bullet and kill/rename the contrib module. Yeah. It looks to me like CUBE will have to be a type_function_name keyword (but hopefully not fully reserved), which will mean that we can't have a contrib module defining a type by that name. Ergo, rename. I am afraid, CUBE and ROLLUP have to be a reserved keyword because as type_function_name is in conflict with func_name ( ... They name to be type_func_keywords, perhaps, but not fully reserved. And they'd still need that treatment anyway. Even if cube(whatever) can't mean extract a column called cube from table whatever, it can still mean call a function called cube on a column called whatever. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is syntax columname(tablename) necessary still?
2010/8/9 Robert Haas robertmh...@gmail.com: On Mon, Aug 9, 2010 at 11:06 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2010/8/9 Tom Lane t...@sss.pgh.pa.us: Greg Stark gsst...@mit.edu writes: Personally I think cube is uncommonly used and CUBE an important enough SQL feature that we should just bite the bullet and kill/rename the contrib module. Yeah. It looks to me like CUBE will have to be a type_function_name keyword (but hopefully not fully reserved), which will mean that we can't have a contrib module defining a type by that name. Ergo, rename. I am afraid, CUBE and ROLLUP have to be a reserved keyword because as type_function_name is in conflict with func_name ( ... They name to be type_func_keywords, perhaps, but not fully reserved. And they'd still need that treatment anyway. Even if cube(whatever) can't mean extract a column called cube from table whatever, it can still mean call a function called cube on a column called whatever. look to gram.y, please. we can use a GROUP BY CUBE(expr, ..) GROUP BY func_name(expr, ..) so these rules are in conflict, because func_name can have a type_func_keywords symbols. So we have to significantly rewrite a rules about func call or CUBE and ROLLUP have to be a reserved words. There isn't any other possibility. regards Pavel -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is syntax columname(tablename) necessary still?
On Mon, Aug 9, 2010 at 11:24 AM, Pavel Stehule pavel.steh...@gmail.com wrote: They name to be type_func_keywords, perhaps, but not fully reserved. And they'd still need that treatment anyway. Even if cube(whatever) can't mean extract a column called cube from table whatever, it can still mean call a function called cube on a column called whatever. look to gram.y, please. we can use a GROUP BY CUBE(expr, ..) GROUP BY func_name(expr, ..) so these rules are in conflict, because func_name can have a type_func_keywords symbols. So we have to significantly rewrite a rules about func call or CUBE and ROLLUP have to be a reserved words. There isn't any other possibility. I understand that you have to make CUBE and ROLLUP reserved words. But you would still have to do that even if we changed $SUBJECT. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is syntax columname(tablename) necessary still?
2010/8/9 Robert Haas robertmh...@gmail.com: On Mon, Aug 9, 2010 at 11:24 AM, Pavel Stehule pavel.steh...@gmail.com wrote: They name to be type_func_keywords, perhaps, but not fully reserved. And they'd still need that treatment anyway. Even if cube(whatever) can't mean extract a column called cube from table whatever, it can still mean call a function called cube on a column called whatever. look to gram.y, please. we can use a GROUP BY CUBE(expr, ..) GROUP BY func_name(expr, ..) so these rules are in conflict, because func_name can have a type_func_keywords symbols. So we have to significantly rewrite a rules about func call or CUBE and ROLLUP have to be a reserved words. There isn't any other possibility. I understand that you have to make CUBE and ROLLUP reserved words. But you would still have to do that even if we changed $SUBJECT. I am not sure if I understand well. yes - CUBE and ROLLUP have to be reserved keywords - and I don't calculate with removing a obsolete syntax now. Regards Pavel -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
