Sunday, August 24, 2008

Re: [HACKERS] Extending error-location reports deeper into the system

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> If we didn't set the locations to unknown, then errors complaining about
> problems arising within a rule would try to print pointers to locations in
> the calling query's text having the same offsets as the problematic item had
> in the original CREATE RULE or similar command. Not what we want.

Just an idle thought... we could include the original source text with the
rule as well. Though how easy it would be to use when we expand the rule is
another question.

It would be useful for the "recompile view" type functionality that people
want for cases like adding a column to an underlying table that they're
reading in the view with "select *". Or people who swap columns around with
alter table and want the view to use new columns that now have the old names.

It would also be useful for debugging if you're looking at pg_dump output of
the reconstructed rule and could compare it with a commented-out original
definition to help understand what the original intent was and why it might
differ from the current definition.

The original objection included caveats that there may be other sites that
have uncertainty about whether to include the line number. Are you sure there
aren't any?

Are you sure there isn't anywhere else lurking that expects equal to really
mean equal? Perhaps someplace that builds a list and expects to eliminate
duplicates?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

No comments: