Thread: 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
Attachment
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
>
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
>
>
>
> -----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.
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
> -----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.
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
> -----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.
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
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
Hiroshi Saito wrote: >I am sleepy fo JST time.:-) > Can't understand that, 22:30 is best working time! Regards, Andreas
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