This is a specific use case, I have a big table without a pk. Updates with
ctid are blazing fast even without an index. I dont need it.
The argument behind this is that users excpect this functionality, its not
just me. Search stackoverflow. They end up using various suboptimal
solutions as I desc
I use ctid as a row identifier within a transaction in a Java application.
To obtain the row ctid I either have to
- cast it to text and store it as String
- cast it to string, then convert it to a bigint using UDF which is
inefficient
I wish I could just cast ctid to bigint and store it
On Saturday, April 17, 2021, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Sat, Apr 17, 2021 at 10:58 AM Vladimír Houba ml.
> > wrote:
> >> Another nice feature would be a function that can be called from a sql
> >> statement and would throw an exception when executed.
>
> > An assertion
On Sat, Apr 17, 2021 at 12:58 PM Vladimír Houba ml.
wrote:
> I use ctid as a row identifier within a transaction in a Java application.
>
This doesn't present a very compelling argument since an actual user
declared primary key is what is expected to be used as a row identifier.
And as those are
"David G. Johnston" writes:
> On Sat, Apr 17, 2021 at 10:58 AM Vladimír Houba ml.
> wrote:
>> Another nice feature would be a function that can be called from a sql
>> statement and would throw an exception when executed.
> An assertion-related extension in core would be welcomed.
This has been
On Sat, Apr 17, 2021 at 10:58 AM Vladimír Houba ml.
wrote:
> I propose to implement a builtin and efficient bidirectional cast between
> ctid and bigint types.
>
>
Why?
> Another nice feature would be a function that can be called from a sql
> statement and would throw an exception when execut
