Thread: some more error location support
Here are three patches to add more detailed error location support to some parts of CREATE TABLE (defaults, check constraints, partition specifications) as well as the COPY command. Examples can be seen in the regression test output. The first two are low-hanging fruit, since all the information was already collected and just needed to be passed through one last hop. The third one is a bit more invasive; it adds location information to the Value node, which is used in a variety of commands, so COPY is just a start here. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
Hello Peter,
> Here are three patches to add more detailed error location support to
> some parts of CREATE TABLE (defaults, check constraints, partition
> specifications) as well as the COPY command. Examples can be seen in
> the regression test output.
>
> The first two are low-hanging fruit, since all the information was
> already collected and just needed to be passed through one last hop.
> The third one is a bit more invasive; it adds location information to
> the Value node, which is used in a variety of commands, so COPY is just
> a start here.
Patch 1 applies cleanly, compiles, "make check" is okay.
I noticed that you provide NULL from "ALTER TABLE" which is calling the
create table machinery:
postgres=# CREATE TABLE foo(id SERIAL CHECK (x = 0));
ERROR: column "x" does not exist
LINE 1: CREATE TABLE foo(id SERIAL CHECK (x = 0));
^
postgres=# CREATE TABLE foo();
CREATE TABLE
postgres=# ALTER TABLE foo ADD COLUMN id SERIAL CHECK (x = 0);
ERROR: column "x" does not exist
<no location>
Would it be easily possible to provide the query in that case as well?
--
Fabien.
On 27/08/2018 10:41, Fabien COELHO wrote: > I noticed that you provide NULL from "ALTER TABLE" which is calling the > create table machinery: The structure of the ALTER TABLE code is such that it would be quite complicated to pass through the required state. It's doable, but would be a bigger and independent project. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>> I noticed that you provide NULL from "ALTER TABLE" which is calling the >> create table machinery: > > The structure of the ALTER TABLE code is such that it would be quite > complicated to pass through the required state. It's doable, but would > be a bigger and independent project. Ok, so no "easy" way about that. I'd consider providing a comment about that. -- Fabien.
Hello Peter, > Here are three patches to add more detailed error location support to > some parts of CREATE TABLE (defaults, check constraints, partition > specifications) as well as the COPY command. Examples can be seen in > the regression test output. > > The first two are low-hanging fruit, since all the information was > already collected and just needed to be passed through one last hop. > The third one is a bit more invasive; it adds location information to > the Value node, which is used in a variety of commands, so COPY is just > a start here. About patch 2: applies cleanly independently of the first one, compiles, "make check" is ok. There is a "make_parsestate", but no corresponding free. The usual pattern, although there seems to be a few exception, is to "make" and "free". Even if there is some under-the-hood garbage collection, I'd suggest to add a free after the call to ComputePartitionAttrs. -- Fabien.
> Here are three patches to add more detailed error location support to > some parts of CREATE TABLE (defaults, check constraints, partition > specifications) as well as the COPY command. Examples can be seen in > the regression test output. > > The first two are low-hanging fruit, since all the information was > already collected and just needed to be passed through one last hop. > The third one is a bit more invasive; it adds location information to > the Value node, which is used in a variety of commands, so COPY is just > a start here. About patch 3: applies cleanly independently of the 2 others, compiles, "make check" is okay. A few comments: There seems to be several somehow unrelated changes: one about copy, one about trigger and one about constraints? The two later changes do not seem to impact the tests, though. In "CreateTrigger", you moved "make_parsestate" but removed "free_parsestate". I'd rather move it than remove it. In "value.h", the added location field deserves a "/* token location, or -1 if unknown */" comment like others in "parsenode.h", "plannode.h" and "primnodes.h". Copying and comparing values are updaed, but value in/out functions are not updated to read/write the location, although other objects have their location serialized. ISTM that it should be done as well. -- Fabien.
On 27/08/2018 10:53, Fabien COELHO wrote: > There is a "make_parsestate", but no corresponding free. The usual > pattern, although there seems to be a few exception, is to "make" and > "free". > > Even if there is some under-the-hood garbage collection, I'd suggest to > add a free after the call to ComputePartitionAttrs. Hmm, I didn't know about free_parsestate(). It doesn't seem to be used consistently. I suppose you'll want to use it when you have a target relation that will be closed by it, but otherwise, for DDL commands, it's not all that useful. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>> Even if there is some under-the-hood garbage collection, I'd suggest to >> add a free after the call to ComputePartitionAttrs. > > Hmm, I didn't know about free_parsestate(). It doesn't seem to be used > consistently. I suppose you'll want to use it when you have a target > relation that will be closed by it, but otherwise, for DDL commands, > it's not all that useful. Probably. The majority rule (34 make & 22 free) suggest that it is more often use than not. I'd suggest to stick to that for consistency & homogeneity. -- Fabien.
On 28/08/2018 08:58, Fabien COELHO wrote: > >>> Even if there is some under-the-hood garbage collection, I'd suggest to >>> add a free after the call to ComputePartitionAttrs. >> >> Hmm, I didn't know about free_parsestate(). It doesn't seem to be used >> consistently. I suppose you'll want to use it when you have a target >> relation that will be closed by it, but otherwise, for DDL commands, >> it's not all that useful. > > Probably. > > The majority rule (34 make & 22 free) suggest that it is more often use > than not. I'd suggest to stick to that for consistency & homogeneity. But it's consistently not used in DDL command implementations, only in normal query parsing. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 27/08/2018 11:17, Fabien COELHO wrote: > About patch 3: applies cleanly independently of the 2 others, compiles, > "make check" is okay. > > A few comments: > > There seems to be several somehow unrelated changes: one about copy, > one about trigger and one about constraints? The two later changes do not > seem to impact the tests, though. added more tests > In "CreateTrigger", you moved "make_parsestate" but removed > "free_parsestate". I'd rather move it than remove it. See also previous discussion, but I've moved it around for now. > In "value.h", the added location field deserves a "/* token location, or > -1 if unknown */" comment like others in "parsenode.h", "plannode.h" and > "primnodes.h". done > Copying and comparing values are updaed, but value in/out functions are > not updated to read/write the location, although other objects have their > location serialized. ISTM that it should be done as well. Hmm, maybe that's a problem, because the serialization of a Value node is just a scalar. It doesn't have any structure where to put additional fields. Maybe we should think about not using Value as a parse representation for column name lists. Let me think about that. Attached is another patch set. I think the first two patches are OK now, but the third one might need to be rethought. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
>> The majority rule (34 make & 22 free) suggest that it is more often use >> than not. I'd suggest to stick to that for consistency & homogeneity. > > But it's consistently not used in DDL command implementations, only in > normal query parsing. I try to avoid complicated (context-sensitive) rules when I can, esp as some functions may be called from DDL and DML. But fine with me. -- Fabien.
On 29/08/2018 16:39, Fabien COELHO wrote: > >>> The majority rule (34 make & 22 free) suggest that it is more often use >>> than not. I'd suggest to stick to that for consistency & homogeneity. >> >> But it's consistently not used in DDL command implementations, only in >> normal query parsing. > > I try to avoid complicated (context-sensitive) rules when I can, esp as > some functions may be called from DDL and DML. > > But fine with me. Committed 0001 and 0002, keeping 0003 for future research, as discussed. Thanks. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services