Thread: is syntax columname(tablename) necessary still?
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. 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. The "cube" issue can be solved without removing this feature too. We have to check every funcname on equality to "cube" or "rollup" string. Is this method acceptable? Regards Pavel Stehule
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 <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@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
On Mon, Aug 9, 2010 at 2:02 PM, David Fetter <david@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
On Mon, Aug 09, 2010 at 02:23:55PM +0100, Greg Stark wrote: > On Mon, Aug 9, 2010 at 2:02 PM, David Fetter <david@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 <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@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
2010/8/9 Greg Stark <gsstark@mit.edu>: > On Mon, Aug 9, 2010 at 2:02 PM, David Fetter <david@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 >
Greg Stark <gsstark@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
Pavel Stehule <pavel.stehule@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
2010/8/9 Tom Lane <tgl@sss.pgh.pa.us>: > Pavel Stehule <pavel.stehule@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 >
On Mon, Aug 9, 2010 at 10:45 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > 2010/8/9 Tom Lane <tgl@sss.pgh.pa.us>: >> Pavel Stehule <pavel.stehule@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
2010/8/9 Tom Lane <tgl@sss.pgh.pa.us>: > Greg Stark <gsstark@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 >
On Mon, Aug 9, 2010 at 11:06 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > 2010/8/9 Tom Lane <tgl@sss.pgh.pa.us>: >> Greg Stark <gsstark@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
2010/8/9 Robert Haas <robertmhaas@gmail.com>: > On Mon, Aug 9, 2010 at 11:06 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: >> 2010/8/9 Tom Lane <tgl@sss.pgh.pa.us>: >>> Greg Stark <gsstark@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 >
On Mon, Aug 9, 2010 at 11:24 AM, Pavel Stehule <pavel.stehule@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
2010/8/9 Robert Haas <robertmhaas@gmail.com>: > On Mon, Aug 9, 2010 at 11:24 AM, Pavel Stehule <pavel.stehule@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 >