Also I have issue with this command:
pg_dump -d 'postgresql://postgres@host.internal?sslmode=require' --create
--clean --if-exists mydb
pg_dump: error: too many command-line arguments (first is "userdb")
pg_dump: hint: Try "pg_dump --help" for more information.
I want to connect to 'postgres' dat
No, it does not. If you refer to `An empty grantee field in an aclitem
stands for PUBLIC.` then "grantee field" was never described. What is
this?
It would be very clear if it was described in this way:
The access privileges has the following format: "grantee=privileges/who grants".
On Sun, Dec
Only here I found explicit mention that recovery.signal will be
removed:
https://www.postgresql.org/docs/16/continuous-archiving.html#BACKUP-PITR-RECOVERY
see p8.
On Thu, Oct 5, 2023 at 10:06 AM PG Doc comments form
wrote:
>
> The following documentation comment has been logged on the website:
>
Did not know that page even exists.
No need to enumerate. It would be nice if you mention that `This tool is
not suitable for restoring data in different major version`.
On Mon, Sep 18, 2023 at 4:08 PM Laurenz Albe
wrote:
> On Mon, 2023-09-18 at 15:29 +, PG Doc comments form wrote:
> > The
ss and actually store Zx5 into field
-- Delete this insert row
-- So user should get back that the value Z was deleted and not Zx5.
Correct?
but currently user will see Zx5, because next code:
OLD.value = uncompress( OLD.value );
does not effect RETURNING =(
--
Best regards,
Eugen Konkov
Hello Eugen,
> https://dbfiddle.uk/?rdbms=postgres_12&fiddle=95ed9fab6870d7c4b6266ea4d93def13
sorry, forget to update link to the latest example:
https://dbfiddle.uk/?rdbms=postgres_12&fiddle=8e114ccc9f15a30ca3115cdc6c70d247
--
Best regards,
Eugen Konkov
FAIL (behavior is not
expected)
This is inconsistent to allow modify output data for UPDATE and
restrict to do this for DELETE
Thank you
--
Best regards,
Eugen Konkov
Hello Eugen,
Saturday, November 9, 2019, 2:05:02 PM, you wrote:
> Hello Bruce,
> Friday, November 8, 2019, 12:28:18 AM, you wrote:
>> On Thu, Nov 7, 2019 at 04:26:55PM -0500, Bruce Momjian wrote:
>>> On Thu, Nov 7, 2019 at 11:24:29AM +0200, Eugen Konkov wrote:
>&g
Hello Bruce,
Friday, November 8, 2019, 12:28:18 AM, you wrote:
> On Thu, Nov 7, 2019 at 04:26:55PM -0500, Bruce Momjian wrote:
>> On Thu, Nov 7, 2019 at 11:24:29AM +0200, Eugen Konkov wrote:
>> > >> As far as allowing DELETE to modify the trigger row for RETURNING, I
cribed at first letter, without
> this the RETURNING rows **does not correspond actually deleted data**
> Thank you.
--
Best regards,
Eugen Konkov
". Becuase, as I have described at first letter, without
this the RETURNING rows **does not correspond actually deleted data**
Thank you.
--
Best regards,
Eugen Konkov
regards,
Eugen Konkov
lt is:
( 7, '[2019-01-01,2020-01-01)', 130 )
You can see that this is original data.
So, does INSTEAD OF DELETE support modification of row?
--
Best regards,
Eugen Konkov
aph:
>Also, some element types have a notion of “infinity”, but that is just another
>value so far as the range type mechanisms are concerned.
errr... mechanism of date ranges violates basic rules for 'Infinite
(Unbounded) Ranges'?
--
Best regards,
Eugen Konkov
1.
Also I found next ambiguous part:
select upper_inf( '["2018-08-14","Infinity")'::daterange );
Thanks jstag from IRC for explanation that unbound and infinite are
different essence.
Thus, on the page
https://www.postgresql.org/docs/11/functions-range.html
lower_inf(anyrange) bool
hat NULL is converted to empty string. This
looks ugly. =(
--
Best regards,
Eugen Konkov
t.
LATERAL != LEFT JOIN LATERAL
it would be more clear if DOC will be more explicit.
> regards, tom lane
--
Best regards,
Eugen Konkov
17 matches
Mail list logo