Re: Some pgAdmin bugs...

Thanks for educating me there Dave, do you also know why and when this
decision was made?

On Tue, Sep 10, 2019 at 10:17 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Tue, Sep 10, 2019 at 12:36 PM Avin Kavish <avinkavish(at)gmail(dot)com> wrote:
>
>> Isn't there some internal uniqueness tracking mechanism? Object IDs or
>> something?
>>
>
> OIDs are deprecated and have been for years. They're removed from user
> tables entirely from v12.
>
>
>>
>> On Tue., 10 Sep. 2019, 9:56 pm Dave Page, <dpage(at)pgadmin(dot)org> wrote:
>>
>>>
>>>
>>> On Tue, Sep 10, 2019 at 9:24 AM Arni Kromić <arni(dot)kromic(at)bios-ict(dot)hr>
>>> wrote:
>>>
>>>> On 10/09/2019 14.42, richard coleman wrote:
>>>>
>>>> Dave,
>>>>
>>>> While I agree it's generally a good idea to have a primary key, the
>>>> solution as currently implemented leaves the user unable to edit, or in
>>>> this case to even add a record to table without one. I would suggest
>>>> either having pgAdmin4 compute some sort of an *internal key* for
>>>> cases like this, or in the alternative *disable* those features (such
>>>> as View/*Edit*) that have not been implemented for cases such as
>>>> this. Perhaps with a dialog informing the user that "Editing or adding
>>>> data isn't supported on tables without a primary key".
>>>>
>>>> rik.
>>>>
>>>> I agree this is a corner case as mentioned. However, sometimes PK-s (or
>>>> indexes) are simply not needed, say if the table is insert-only most of the
>>>> time and its data gets dumped without any filters, and nothing ever needs
>>>> to be deleted. I believe Inserts should also work from pgAdmin as they do
>>>> from code.
>>>>
>>>> So, should a issue be raised, or is it already decided this is a
>>>> "wontfix"?
>>>>
>>>
>>> No, it's not decided. Feel free to add a feature request, but it's
>>> likely to be considered low priority.
>>>
>>>
>>>> --
>>>> Kind Regards,
>>>> Arni Kromić
>>>>
>>>>
>>>> On Tue, Sep 10, 2019 at 8:34 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 10, 2019 at 8:24 AM richard coleman <
>>>>> rcoleman(dot)ascentgl(at)gmail(dot)com> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> My $0.02. Tested the first one here (Kubuntu 18.04, Chromium,
>>>>>> pgAdmin 4 4.12) with mixed results.
>>>>>>
>>>>>> On Tue, Sep 10, 2019 at 7:59 AM Aditya Toshniwal <
>>>>>> aditya(dot)toshniwal(at)enterprisedb(dot)com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Tue, Sep 10, 2019 at 5:13 PM Arni Kromić <arni(dot)kromic(at)bios-ict(dot)hr>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Working with pgAdmin, I've found several bugs. Not sure if they are
>>>>>>>> already reported; couldn't find them on Redmine, but perhaps I missed them.
>>>>>>>> Maybe someone will recognize if they've already been reported. Here it
>>>>>>>> goes...
>>>>>>>>
>>>>>>>> 1) When doing View/Edit on an empty table, I cannot insert anything
>>>>>>>> when it opens. There is no empty row I can write into, like there is when a
>>>>>>>> table has at least one row already. In fact, there are no rows at all, just
>>>>>>>> the header.
>>>>>>>>
>>>>>>> I tried. I get an empty row to enter
>>>>>>> [image: Screenshot 2019-09-10 at 17.25.25.png]
>>>>>>>
>>>>>>>
>>>>>> Test table0: two columns both character varying columns, no primary
>>>>>> key, View/Edit opens without any rows as the original poster Arni wrote.
>>>>>>
>>>>>> Test table1: three columns, two character varying, one primary key
>>>>>> bigint, View/Edit opens with a single blank row as Aditya reported.
>>>>>>
>>>>>> Does Arni's table have a primary key defined? Is it a bigint? It
>>>>>> looks like there might be a bug where pgAdmin4 isn't presenting a row to
>>>>>> add a record from the View/Edit function if there isn't a primary key, or a
>>>>>> particular type of primary key defined on the table.
>>>>>>
>>>>>
>>>>> If memory serves that was a design choice when the code was
>>>>> implemented. We cannot safely allow editing without a primary key, and
>>>>> adding rows (which arguably is safe) is considered editing as the code is
>>>>> currently implemented.
>>>>>
>>>>> I consider this a corner-case; typically one would have a primary key
>>>>> on a table to identify individual rows, and most cases where you wouldn't
>>>>> are probably not ones where you'd ever try to edit or manually add data
>>>>> (consider something like sensor output data). I'm not sure how much demand
>>>>> there would be for doing this; clearly not a huge amount.
>>>>>
>>>>> --
>>>>> Dave Page
>>>>> Blog: http://pgsnake.blogspot.com
>>>>> Twitter: @pgsnake
>>>>>
>>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>>> The Enterprise PostgreSQL Company
>>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>