Thread: pgAggregate problem any function

pgAggregate problem any function

From
"Hiroshi Saito"
Date:
Hi Andreas.

There is a problem by handling of any of the input type.

This patch will just be able to do it.
any -> "any"

But,
Is it likely to be the problem of parser of postgresql?
"ANY" is written in the document.
But, drop isn't made though "ANY" can be registered.

This is with psql.
saito=# DROP AGGREGATE public.newcnt(any);
ERROR:  syntax error at or near "any" at character 30
saito=# DROP AGGREGATE public.newcnt(ANY);
ERROR:  syntax error at or near "ANY" at character 30
saito=# DROP AGGREGATE public.newcnt("ANY");
ERROR:  type "ANY" does not exist
saito=# DROP AGGREGATE public.newcnt("any");
DROP AGGREGATE

Any Comment?

Regards,
Hiroshi Saito

Attachment

Re: pgAggregate problem any function

From
"Dave Page"
Date:
Thanks Hiroshi, patch applied (I ran into that problem in pga2!)

Regards, Dave.

> -----Original Message-----
> From: Hiroshi Saito [mailto:saito@inetrt.skcapi.co.jp]
> Sent: 09 September 2003 06:17
> To: Andreas Pflug
> Cc: pgadmin-hackers@postgresql.org; Dave Page
> Subject: pgAggregate problem any function
>
>
> Hi Andreas.
>
> There is a problem by handling of any of the input type.
>
> This patch will just be able to do it.
> any -> "any"
>
> But,
> Is it likely to be the problem of parser of postgresql?
> "ANY" is written in the document.
> But, drop isn't made though "ANY" can be registered.
>
> This is with psql.
> saito=# DROP AGGREGATE public.newcnt(any);
> ERROR:  syntax error at or near "any" at character 30
> saito=# DROP AGGREGATE public.newcnt(ANY);
> ERROR:  syntax error at or near "ANY" at character 30
> saito=# DROP AGGREGATE public.newcnt("ANY");
> ERROR:  type "ANY" does not exist
> saito=# DROP AGGREGATE public.newcnt("any");
> DROP AGGREGATE
>
> Any Comment?
>
> Regards,
> Hiroshi Saito
>

Re: pgAggregate problem any function

From
Andreas Pflug
Date:
Hm,

looking at the patch and the weird pgsql behaviour documented below I
doubt that this is the ultimate fix.
I suspect that
a) this should be handled in qtIdent()
b) other keywords might be affected, e.g. 'char'

Regards,
Andreas



Dave Page wrote:

>Thanks Hiroshi, patch applied (I ran into that problem in pga2!)
>
>Regards, Dave.
>
>
>
>>-----Original Message-----
>>From: Hiroshi Saito [mailto:saito@inetrt.skcapi.co.jp]
>>Sent: 09 September 2003 06:17
>>To: Andreas Pflug
>>Cc: pgadmin-hackers@postgresql.org; Dave Page
>>Subject: pgAggregate problem any function
>>
>>
>>Hi Andreas.
>>
>>There is a problem by handling of any of the input type.
>>
>>This patch will just be able to do it.
>>any -> "any"
>>
>>But,
>>Is it likely to be the problem of parser of postgresql?
>>"ANY" is written in the document.
>>But, drop isn't made though "ANY" can be registered.
>>
>>This is with psql.
>>saito=# DROP AGGREGATE public.newcnt(any);
>>ERROR:  syntax error at or near "any" at character 30
>>saito=# DROP AGGREGATE public.newcnt(ANY);
>>ERROR:  syntax error at or near "ANY" at character 30
>>saito=# DROP AGGREGATE public.newcnt("ANY");
>>ERROR:  type "ANY" does not exist
>>saito=# DROP AGGREGATE public.newcnt("any");
>>DROP AGGREGATE
>>
>>Any Comment?
>>
>>Regards,
>>Hiroshi Saito
>>
>>
>>
>
>---------------------------(end of broadcast)---------------------------
>TIP 3: if posting/reading through Usenet, please send an appropriate
>      subscribe-nomail command to majordomo@postgresql.org so that your
>      message can get through to the mailing list cleanly
>
>
>



Re: pgAggregate problem any function

From
"Dave Page"
Date:

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 09 September 2003 11:50
> To: Dave Page
> Cc: Hiroshi Saito; pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] pgAggregate problem any function
>
>
> Hm,
>
> looking at the patch and the weird pgsql behaviour documented below I
> doubt that this is the ultimate fix.
> I suspect that
> a) this should be handled in qtIdent()
> b) other keywords might be affected, e.g. 'char'

We looked at this in pga2 (and I think Frank did implement something in
the end). The problem is that there is a huge list of reserved words
that need checking
(http://www.postgresql.org/docs/7.3/static/sql-keywords-appendix.html),
90% of which noone is ever likely to name a type or domain after. Is it
worth the overhead of searching the list in every call to qtIdent?

Regards, Dave.

Re: pgAggregate problem any function

From
Andreas Pflug
Date:
Dave Page wrote:

>
>
>>-----Original Message-----
>>From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
>>Sent: 09 September 2003 11:50
>>To: Dave Page
>>Cc: Hiroshi Saito; pgadmin-hackers@postgresql.org
>>Subject: Re: [pgadmin-hackers] pgAggregate problem any function
>>
>>
>>Hm,
>>
>>looking at the patch and the weird pgsql behaviour documented below I
>>doubt that this is the ultimate fix.
>>I suspect that
>>a) this should be handled in qtIdent()
>>b) other keywords might be affected, e.g. 'char'
>>
>>
>
>We looked at this in pga2 (and I think Frank did implement something in
>the end). The problem is that there is a huge list of reserved words
>that need checking
>(http://www.postgresql.org/docs/7.3/static/sql-keywords-appendix.html),
>90% of which noone is ever likely to name a type or domain after. Is it
>worth the overhead of searching the list in every call to qtIdent?
>
Didn't want to check all keywords, but there are some treated special,
and one of them is "char". I was wondering if "any" will make problems
in other places too, that's why I'd like to see it in qtIdent().

Regards,
Andreas



Re: pgAggregate problem any function

From
"Dave Page"
Date:

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 09 September 2003 12:16
> To: Dave Page
> Cc: Hiroshi Saito; pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] pgAggregate problem any function
>
>
> Didn't want to check all keywords, but there are some treated special,

> and one of them is "char". I was wondering if "any" will make problems

> in other places too, that's why I'd like to see it in qtIdent().

I guess we should really check them all. Can we jsut lift the relevant
bits of
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/pars
er/keywords.c?rev=1.141&content-type=text/x-cvsweb-markup, or would you
prefer it was done a different way?

Regards, Dave.


Re: pgAggregate problem any function

From
Andreas Pflug
Date:
Dave Page wrote:

>
>I guess we should really check them all. Can we jsut lift the relevant
>bits of
>http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/pars
>er/keywords.c?rev=1.141&content-type=text/x-cvsweb-markup, or would you
>prefer it was done a different way?
>
I just added this to qtIdent using the original pgsql files, but I
wasn't too happy with it currently commented out).

We need to have at least two qtIdent varieties, because there are cases
when we *need* non-quoted keywords.

while
CREATE TABLE (colname "char")
is valid,
CREATE TABLE (colname "char"(20))
is not.

Regards,
Andreas


Re: pgAggregate problem any function

From
"Dave Page"
Date:

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 09 September 2003 13:55
> To: Dave Page
> Cc: Hiroshi Saito; pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] pgAggregate problem any function
>
>
> Dave Page wrote:
>
> >
> >I guess we should really check them all. Can we jsut lift
> the relevant
> >bits of
> >http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/b
ackend/par
>s
>er/keywords.c?rev=1.141&content-type=text/x-cvsweb-markup, or would you
>prefer it was done a different way?
>
> I just added this to qtIdent using the original pgsql files, but I
> wasn't too happy with it currently commented out).

Hmm. Currently it breaks the build because parser/keywords.h is missing.
keywords.c istelf has a bunch of additional includes that won't be there
as well.

> We need to have at least two qtIdent varieties, because there are
cases
> when we *need* non-quoted keywords.
>
> while
> CREATE TABLE (colname "char")
> is valid,
> CREATE TABLE (colname "char"(20))
> is not.

Urggh, I see what you mean. There will also be a fine distinction
between the two functions which I can see introducing a few bugs along
these lines.

We've had no complaints about keywords causing problems anywhere (in
pga2 or pga3), and the aggregate problem is obviously a real one - I
vote we go with Hiroshi's patch for now, and take a closer look for the
next version. The number of places qtIdent is used, I think there is too
much scope to accidently break things in the way you demonstrated above
this close to release.

Regards, Dave.

Re: pgAggregate problem any function

From
Andreas Pflug
Date:
Dave Page wrote:

>
>
>>-----Original Message-----
>>From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
>>Sent: 09 September 2003 13:55
>>To: Dave Page
>>Cc: Hiroshi Saito; pgadmin-hackers@postgresql.org
>>Subject: Re: [pgadmin-hackers] pgAggregate problem any function
>>
>>
>>Dave Page wrote:
>>
>>
>>
>>>I guess we should really check them all. Can we jsut lift
>>>
>>>
>>the relevant
>>
>>
>>>bits of
>>>http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/b
>>>
>>>
>ackend/par
>
>
>>s
>>er/keywords.c?rev=1.141&content-type=text/x-cvsweb-markup, or would you
>>prefer it was done a different way?
>>
>>I just added this to qtIdent using the original pgsql files, but I
>>wasn't too happy with it currently commented out).
>>
>>
>
>Hmm. Currently it breaks the build because parser/keywords.h is missing.
>keywords.c istelf has a bunch of additional includes that won't be there
>as well.
>
>
I added all to cvs, copying them from pgsql or creating dummy ones.
linux not done yet.

>We've had no complaints about keywords causing problems anywhere (in
>pga2 or pga3), and the aggregate problem is obviously a real one - I
>vote we go with Hiroshi's patch for now, and take a closer look for the
>next version. The number of places qtIdent is used, I think there is too
>much scope to accidently break things in the way you demonstrated above
>this close to release.
>
Agreed.

Regards,
Andreas



Re: pgAggregate problem any function

From
"Hiroshi Saito"
Date:
From: "Andreas Pflug" <pgadmin@pse-consulting.de>

> Dave Page wrote:
(snip)
> >We've had no complaints about keywords causing problems anywhere (in
> >pga2 or pga3), and the aggregate problem is obviously a real one - I
> >vote we go with Hiroshi's patch for now, and take a closer look for the
> >next version. The number of places qtIdent is used, I think there is too
> >much scope to accidently break things in the way you demonstrated above
> >this close to release.
> >
> Agreed.

To make a better thing. too.
I am sleepy fo JST time.:-)

Regards,
Hiroshi Saito

Re: pgAggregate problem any function

From
Andreas Pflug
Date:
Hiroshi Saito wrote:

>I am sleepy fo JST time.:-)
>
Can't understand that, 22:30 is best working time!

Regards,
Andreas



Re: pgAggregate problem any function

From
"Hiroshi Saito"
Date:
From: "Andreas Pflug" <pgadmin@pse-consulting.de>

> Hiroshi Saito wrote:
>
> >I am sleepy fo JST time.:-)
> >
> Can't understand that, 22:30 is best working time!
>
Oh.
I must seem to fight against the iron person.
I go to buy "time" in the department store.:-)

Regards,
Hiroshi Saito