Re: [EXT] Re: Can we get the CTID value - Mailing list pgsql-general

From Garfield Lewis
Subject Re: [EXT] Re: Can we get the CTID value
Date
Msg-id 6CCE2477-12BB-4287-9CE0-3DBFB3E6652D@lzlabs.com
Whole thread Raw
In response to Re: [EXT] Re: Can we get the CTID value  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [EXT] Re: Can we get the CTID value  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
> On 2022-01-20, 12:52 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>
>    Garfield Lewis <garfield.lewis@lzlabs.com> writes:
>    > I need the page and possibly row of the data location to be stored as an element of the new type. This is to
simulatea structure from another database system.
 
>
>    You need to rethink.  The datatype input function cannot know even that
>    the value is going to be stored anywhere, let alone exactly where.
>    Moreover, what would happen if the row is moved somewhere else due
>    to an update of some other column?
>
>    You might be able to build something for cross-linking by putting
>    the logic in AFTER INSERT/UPDATE/DELETE triggers, but I think a
>    custom datatype is not going to be helpful for that.
>
>                regards, tom lane

Thx, Tom...

I think you are right in the case of INPUT/RECEIVE, however we should be able to get that info during OUTPUT/SEND (I
think)since it is fixed at that point. At the time I return the information to the user I could augment the output to
addthat information to the output. However, I still don't know if it is even possible to get that information in those
functions.Is that at all possible?
 

Regards,
Garfield


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Query much slower from php than psql or dbeaver
Next
From: Tom Lane
Date:
Subject: Re: [EXT] Re: Can we get the CTID value