Re: Extending error-location reports deeper into the system
От | Gregory Stark |
---|---|
Тема | Re: Extending error-location reports deeper into the system |
Дата | |
Msg-id | 87myj2b61c.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Extending error-location reports deeper into the system (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Extending error-location reports deeper into the system
|
Список | pgsql-hackers |
"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!
В списке pgsql-hackers по дате отправления: