Re: Some pgAdmin bugs...

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