On 2022-01-20, 1:11 PM, "Tom Lane" <t...@sss.pgh.pa.us> wrote:
> No, it's the same problem in reverse: the output function cannot
> know where the value came from. There is no hard and fast
> reason that it must have come out of a table, either. Consider
> something as simple as
>
> SELECT 'blah blah'::yourtype;
>
> This'll invoke the type's input function to parse the literal string,
> and later it'll invoke the output function to reconstruct a string
>
> to send to the client, and there's no table involved.
>
> regards, tom lane
Understood, however, my last question/comment would be shouldn't the example
above just result in a CTID something like (x,y) where x and y are some known
UNKNOWN/INVALID values or something else representing the fact that there is no
current CTID associated with the element? Basically, what I am saying is
shouldn't any search for a CTID in the case just return some value to indicate
the CTID doesn't exist or is UNKNOWN/INVALID?
The following knows there is no CTID so shouldn’t I be able to get something
similar programmatically?
[sysprog@nucky lz_pgmod] (h-master-LZRDB-4714)*$ psql -U postgres -d postgres
-c "select ctid, 'test'"
ERROR: column "ctid" does not exist
LINE 1: select ctid, 'test'
^
Regards,
Garfield
