On 27.2.2015 20:49, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>> On 27.2.2015 20:34, Alvaro Herrera wrote:
>>> Tomas Vondra wrote:
>>>
>>>> I think we could calls to the randomization functions into some of the
>>>> regression tests (say 'create_tables.sql'), but that makes regression
>>>> tests ... well, random, and I'm not convinced that's a good thing.
>>>>
>>>> Also, this makes regression tests harder to think, because "SELECT *"
>>>> does different things depending on the attlognum order.
>>>
>>> No, that approach doesn't seem very useful. Rather, randomize the
>>> columns in the CREATE TABLE statement, and then fix up the attlognums so
>>> that the SELECT * expansion is the same as it would be with the
>>> not-randomized CREATE TABLE.
>>
>> Yes, that's a possible approach too - possibly a better one for
>> regression tests as it fixes the 'SELECT *' but it effectively uses
>> fixed 'attlognum' and 'attnum' values (it's difficult to randomize
>> those, as they may be referenced in other catalogs).
>
> Why would you care what values are used as attnum? If anything
> misbehaves, surely that would be a bug in the patch. (Of course, you
> can't just change the numbers too much later after the fact, because the
> attnum values could have propagated into other tables via foreign keys
> and such; it needs to be done during executing CREATE TABLE or
> immediately thereafter.)
Because attnums are referenced in other catalogs? For example when you
define PRIMARY KEY or UNIQUE constraint in the table, an index is
created, which gets a row in pg_index catalog, and that references the
attnum values in indkey column.
If you just randomize the attnums in pg_attribute (withouth fixing all
the attnum references), it's going to go BOOOOM.
--
Tomas Vondra http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
