Re: Safe operations?

On Mon, 13 Aug 2018 at 12:23, Olivier Gautherot <olivier(at)gautherot(dot)net>
wrote:

> On Sun, Aug 12, 2018 at 11:06 PM, Tim Cross <theophilusx(at)gmail(dot)com> wrote:
>
>>
>> On Mon, 13 Aug 2018 at 11:24, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
>> wrote:
>>
>>> On 08/12/2018 05:41 PM, Samuel Williams wrote:
>>> > I wish the documentation would include performance details, i.e. this
>>> > operation is O(N) or O(1) relative to the number of rows.
>>> >
>>> > I found renaming a table was okay.
>>> >
>>> > How about renaming a column? Is it O(1) or proportional to the amount
>>> of
>>> > data?
>>> >
>>> > Is there any documentation about this?
>>>
>>> https://www.postgresql.org/docs/10/static/sql-altertable.html
>>>
>>> "RENAME
>>>
>>> The RENAME forms change the name of a table (or an index, sequence,
>>> view, materialized view, or foreign table), the name of an individual
>>> column in a table, or the name of a constraint of the table. There is no
>>> effect on the stored data.
>>> "
>>>
>>> Just wondering - what about the case when the column being renamed is
>>> also referenced in an index or check constraint? (I would guess you cannot
>>> rename a column used in a check constraint without first removing it, but
>>> for an index, would this result in the index being rebuilt (or do you have
>>> to take care of that manually or are such references abstracted such that
>>> the column name "text" is irrelevant tot he actual structure of the
>>> index?).
>>
>>
> Tim, as far as I know, names are only an attribute tagged to an OID.
> Internal relations are though these OIDs, not names, so renaming a column
> is really one-shot. Names are mainly a more convenient way of referring to
> objects.
>
> Olivier
>

thanks Olivier, that is what I suspected and your explanation fits with my
mental model. I had assumed table/column names are convenience for humans
and that the system would use OIDs etc for internal references.
--
regards,

Tim

--
Tim Cross