From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | eshkinkot(at)gmail(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #8702: psql \df+ translate_columns[] overflow and unexpected gettext translation |
Date: | 2013-12-30 23:01:07 |
Message-ID: | 668.1388444467@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> There are several places that are similarly broken. See attached patch.
> Obviously, this is not a very robust programming interface, if the same
> mistake has been repeated three times independently.
Yeah :-(. How about adding an Assert as in the attached?
I had to make the Assert say ">=" not just "==" because there are numerous
callers that use the same array for both normal and verbose output.
This seems a bit shaky but it's not actually broken anywhere.
I think.
The breakage in \df appears to be the fault of the addition of a
translated "security definer/invoker" column, which clearly nobody really
tested the translations for, or they'd have noticed that the column
marking in translate_columns[] was wrong :-(. I believe the "translation
support" in \dy (event triggers) is pretty bogus as well.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
check-translate-columns-counts.patch | text/x-diff | 7.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | digoal | 2013-12-31 00:48:46 | BUG #8710: dblink dblink_get_pkey output bug, and dblink_build_sql_update bug |
Previous Message | Andres Freund | 2013-12-30 18:11:51 | Re: BUG #8470: 9.3 locking/subtransaction performance regression |