Thread: is syntax columname(tablename) necessary still?

is syntax columname(tablename) necessary still?

From
Pavel Stehule
Date:
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


Re: is syntax columname(tablename) necessary still?

From
David Fetter
Date:
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


Re: is syntax columname(tablename) necessary still?

From
Greg Stark
Date:
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


Re: is syntax columname(tablename) necessary still?

From
David Fetter
Date:
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


Re: is syntax columname(tablename) necessary still?

From
Pavel Stehule
Date:
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
>


Re: is syntax columname(tablename) necessary still?

From
Tom Lane
Date:
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


Re: is syntax columname(tablename) necessary still?

From
Tom Lane
Date:
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


Re: is syntax columname(tablename) necessary still?

From
Pavel Stehule
Date:
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
>


Re: is syntax columname(tablename) necessary still?

From
Robert Haas
Date:
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


Re: is syntax columname(tablename) necessary still?

From
Pavel Stehule
Date:
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
>


Re: is syntax columname(tablename) necessary still?

From
Robert Haas
Date:
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


Re: is syntax columname(tablename) necessary still?

From
Pavel Stehule
Date:
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
>


Re: is syntax columname(tablename) necessary still?

From
Robert Haas
Date:
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


Re: is syntax columname(tablename) necessary still?

From
Pavel Stehule
Date:
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
>