ReindexStmt does not carry concurrent attribute rather params

[bolajiwahab]

Hi,

I noticed ReindexStmt does not carry concurrent attribute but rather a params attribute with DefElem which contains concurrently when it is a concurrent reindex.

The documentation stated there is a concurrent attribute as seen here https://pglast.readthedocs.io/en/v3/ast.html#:~:text=class%20pglast.ast.ReindexStmt(kind%3DNone%2C%20relation%3DNone%2C%20name%3DNone%2C%20options%3DNone%2C%20concurrent%3DNone)%C2%B6

Version of pglast is 6.2

[lelit]

Hi!

First of all, you are referencing a (now) very old version of pglast (v3) that targets PG13 when the ReindexStmt structure effectively contained that concurrent flag, but that has been dropped in v4/PG14. I'm curious to know why you consulted v3 documentation, when you at last say you are using v6.2.

That said, I think that this is very similar to what I said in issue #150: the parser exposed by libpgquery is slightly different from the real one, in particular it does not execute some of the post-parse analysis that the real one does, as some of those cannot be perfomed without accessing the PG catalog tables (that libpgquery/pglast cannot do), as explained here.

I'm afraid there is little I can do to solve all those cases, surely not on pglast v3, sorry.

[bolajiwahab]

Hi!

First of all, you are referencing a (now) very old version of pglast (v3) that targets PG13 when the ReindexStmt structure effectively contained that concurrent flag, but that has been dropped in v4/PG14. I'm curious to know why you consulted v3 documentation, when you at last say you are using v6.2.

Oh, apologies, I didn't realise I was on v3 in the documentation. Thanks for pointing that out.

That said, I think that this is very similar to what I said in issue #150: the parser exposed by libpgquery is slightly different from the real one, in particular it does not execute some of the post-parse analysis that the real one does, as some of those cannot be perfomed without accessing the PG catalog tables (that libpgquery/pglast cannot do), as explained here.

I'm afraid there is little I can do to solve all those cases, surely not on pglast v3, sorry.

It is fine. I was checking the wrong documentation as against v6 and I thought maybe somehow it was missed out. The good news is that there is an attribute containing the information and this one liner is sufficient for my use-case.

params = [param.defname for param in node.params] if node.params else []

Feel free to close the issue.

Thanks.

[lelit]

Right, thank you.

As said, coming up with list of those post-parse computed attributes is a really daunting task, as it would require human analysis of the PG sources because unfortunately the information does not emerge in neither the PG headers nor in the libpg_query byproducts.