={1,2,3,4,5,6,7}'::int[], 2, NULL) ==
{3,4,5,6,7} -- omitting boundaries
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
siest way, because it allows to avoid
usage of INTERVAL as a helper (of course, there is still possible to
use intervals as shown above in user's scripts, but without "Infinity"
support).
2. Add support of infinite intervals. It is harder, because it touches
a lot of functions. I can ad
on 9.1 proposed test fails because "SELECT
EXTRACT(EPOCH FROM DATE '1970-01-01')" gives "28800" instead of "0".
Before 9.2 it was time zone-related.
--
Best regards,
Vitaly Burovoy.
extract_from_infinite_timestamp-v1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/9/15, Robert Haas <robertmh...@gmail.com> wrote:
> On Sat, Nov 7, 2015 at 9:47 AM, Vitaly Burovoy <vitaly.buro...@gmail.com>
> wrote:
>> I'd like to raise a topic about extracting fields from infinite
>> timestamps, so much more that it is mentioned in th
On 1/4/16, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
> Vitaly Burovoy wrote:
>
>> Majority of the votes for NULL for "other things" except epoch.
>> Nobody answers about differences between monotonic and oscillating
>> values.
>>
>> I s
On 1/8/16, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
> Simon Riggs wrote:
>> On 8 January 2016 at 14:14, Vitaly Burovoy <vitaly.buro...@gmail.com>
>> wrote:
>>
>> > What about SET NOT NULL constraints? There is no VALIDATE CONSTRAINT
>> &g
On 1/8/16, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 8 January 2016 at 13:13, Vitaly Burovoy <vitaly.buro...@gmail.com>
> wrote:
>
>> On 1/8/16, Simon Riggs <si...@2ndquadrant.com> wrote:
>> > On 8 January 2016 at 12:49, Vitaly Bur
t a check for that
special case to raise an exception "timestamp out of range"?
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
USING
INDEX tablename_chk;
DROP INDEX CONCURRENTLY tablename_chk; -- if the command above succeed
ALTER TABLE tablename DROP CONSTRAINT tablename_nonnull_chk; --optional
[1] http://www.postgresql.org/docs/9.1/static/release-9-1.html#AEN110279
[2] http://www.postgresql.org/docs/9.5/static/sql-createt
On 1/8/16, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 8 January 2016 at 12:49, Vitaly Burovoy <vitaly.buro...@gmail.com>
> wrote:
>
>
>> In Postgres9.1 a new feature was implemented [1] for adding PK and
>> UNIQUE constraints using indexes created concu
On 1/8/16, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 8 January 2016 at 13:13, Vitaly Burovoy <vitaly.buro...@gmail.com>
> wrote:
>
>> On 1/8/16, Simon Riggs <si...@2ndquadrant.com> wrote:
>> > On 8 January 2016 at 12:49, Vitaly Bur
On 6/15/16, Michael Paquier <michael.paqu...@gmail.com> wrote:
> On Thu, Jun 16, 2016 at 12:10 PM, Vitaly Burovoy
> <vitaly.buro...@gmail.com> wrote:
>> In the initial letter[1] I posted a digest from the SQL-2011 standard
>> and a conclusion as a design of a new
of SELECT and UPDATE:
http://www.postgresql.org/docs/devel/static/pgcrypto.html#AEN170716
... but recommend to change just "gen_salt('md5')" to "gen_salt('bf', 8))"
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, but there is certainly
> more here than meets the eye; and therefore there's a nonzero chance of
> being blindsided if the SQL committee someday standardizes this syntax
> and makes some different decisions about what it means.
>
> regards, tom lane
Be honest I
input values at app-level.
> ...
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e numeric: "+"
---
+ while (isspace((unsigned char) *strptr))
...
+ while (isspace(*strptr))
...
+ while (*strptr && !isspace(*strptr))
...
+ while (isspace(*strptr))
The first occurece of isspace's parameter is casting to "unsigned
char" wher
On 1/18/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> <>
> ---
> + if (*strptr != '\0')
> ...
> + while (*strptr && !isspace(*strptr))
> Sometimes it explicitly compares to '\0', sometimes implicitly.
> Common use is explicit compar
On 1/14/16, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Vitaly Burovoy <vitaly.buro...@gmail.com> writes:
>> On 1/14/16, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> It's more than syntactic sugar; you are going to have to invent
>>> semantics,
>>> as
ct in some way?
>
> Thanks
> Glyn
I thing the operator 'jsonb-jsonb' behavior in such case is not obvious.
How to understand the result is not like that:
# select '{"a":1, "b":2}'::jsonb - '{"b":2, "a":4}'::jsonb;
?column?
--
{"a": -3,
t'll be
ready to be shown in a month (may be two).
But it already forbids dropping NOT NULLs if they were set as result
of inheritance.
[1]
https://www.postgresql.org/message-id/flat/CAKOSWNkN6HSyatuys8xZxzRCR-KL1OkHS5-b9qd9bf1Rad3PLA%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/attachme
On 2/7/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> Hello, Hackers!
>
> TODO list has an entry "Move NOT NULL constraint information to
> pg_constraint" with four links and without two with the newest
> work[1][2].
>
> I rebased the patch from [2]
free is removed (it is easier than removing all other allocated resources).
I still think my changes are little and they are based on your work
(and research).
[1]http://www.postgresql.org/message-id/cakoswnk13wvdem06lro-hucr0pr6et29+dvqy6j5skxzaru...@mail.gmail.com
--
Best regards,
Vitaly Buro
//www.postgresql.org/message-id/ca+tgmozfomg4eyorzzgf7pzotg9pxpuhtqvxlfskim4izh8...@mail.gmail.com
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello!
I have reviewed this patch. It applies and compiles cleanly at the
current master 1129c2b0ad2732f301f696ae2cf98fb063a4c1f8 and implements
the behavior reached by a consensus.
All size units (the same as used in the GUC) are supported.
The documentation is present and describes behavior
Proposed patch makes that behavior.
P.S.: Should the patch be added to the next CF?
[1]https://docs.oracle.com/cd/E36784_01/html/E36874/fpclass-3c.html
--
Best regards,
Vitaly Burovoy
isinf_v1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
regards, tom lane
Ok, then I'll use "is_infinite" from "float.c".
But why functions' (in "src/port/isinf.c") behavior are different? It
is a bit confusing…
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list
"str" and "buffer".
But if you do so, clean up also buffers from numeric_in, numeric_mul
and int8_numeric. If you insist it should be left as is, I leave that
decision to a committer.
P.S.: Have you thought to wrap the call "numeric_in" by a
PG_TRY/PG_CATCH instead of checkin
,
> false, "error message" instead raising a exception.
I know. It is a common style in C programs.
> I would not to refactor numeric_in function in this style.
No doubt. It is not necessary.
> This function is in critical path of COPY
> FROM, and any more calls can decreas
8721654.78
infinity| Infinity
(4 rows)
--
Best regards,
Vitaly Burovoy
fix_extract_overflow_v1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2/2/16, Tom Lane <t...@sss.pgh.pa.us> wrote:
> [ Please use a useful Subject: line in your posts. ]
I'm so sorry, it was the first time I had forgotten to look at the
"Subject" field before I pressed the "Send" button.
> Vitaly Burovoy <vitaly.buro...@gm
> 0001-06-01 BC
> (1 row)
Also because of:
postgres=# SELECT EXTRACT(year FROM to_date('-3', ''));
date_part
---
-4
(1 row)
Note that the documentation[1] says "Keep in mind there is no 0 AD".
More examples by the link[2].
> --
> R
On 2/24/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> On 2/2/16, Jim Nasby <jim.na...@bluetreble.com> wrote:
>> On 2/2/16 6:39 PM, Tom Lane wrote:
>>> I'm inclined to think that a good solution would be to create an
>>> artificial restriction to
>
Added to the commitfest 2016-03.
[CF] https://commitfest.postgresql.org/9/540/
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
extract options "year"/"isoyear", but I think getting decision of the
community before modifying the patch is a better idea.
[1]http://www.postgresql.org/docs/devel/static/functions-formatting.html
[2]http://www.postgresql.org/docs/devel/static/functions-datetime.html
[3]http://www.postgresql.org/message-id/CAEepm=0aznvy+frtyni04imdw4tlgzaelljqmhmcjbre+ln...@mail.gmail.com
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Added to the CF 2016-03:
https://commitfest.postgresql.org/9/546/
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
3]https://commitfest.postgresql.org/9/540/
[4]http://www.postgresql.org/docs/devel/static/datatype-datetime.html
--
Best regards,
Vitaly Burovoy
to_timestamp_infs.v001.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
*MM*DD BC');
to_timestamp| to_timestamp
---+---
0010-01-01 00:00:00+00 BC | 0010-01-01 00:00:00+00 BC
(1 row)
Testings, complains, advice, comment improvements are very appreciated.
--
Best regards,
Vitaly Burovoy
negative_years_in_to_dat
On 2/22/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> Testings, complains, advice, comment improvements are very appreciated.
The patch seems simple, but it can lead to a discussion, so I've added it to CF.
[CF]https://commitfest.postgresql.org/9/533/
--
Best regards,
Vital
On 2/22/16, Thomas Munro <thomas.mu...@enterprisedb.com> wrote:
> On Tue, Feb 23, 2016 at 11:58 AM, Vitaly Burovoy
> <vitaly.buro...@gmail.com> wrote:
>> Hello, Hackers!
>>
>> I'm writing another patch and while I was trying to cover corner cases
>> I foun
On 1/20/16, Pavel Stehule <pavel.steh...@gmail.com> wrote:
> ...
> New version is attached
>
> Regards
> Pavel
I'm sorry I'll do a review only tonight.
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
adjustments, mainly to make sure that the
> erroneous-units errors exactly match those that would be thrown in
> the main code line.
>
> regards, tom lane
Thank you! I didn't pay enough attention to it at that time.
--
Best regards,
Vitaly Burovoy
--
Sent
ed by
text_to_cstring) and copying into it. I don't think it gives a big
improvement, but nevertheless.
===
[1] http://www.postgresql.org/message-id/29618.1451882...@sss.pgh.pa.us
[2]
http://www.postgresql.org/message-id/CAB7nPqS6Wob4WnZb=dhb3o0pc-nx1v3xjszkn3z9kbexgcq...@mail.gmail.com
--
Best
Hello, Pavel!
That letter was not a complain against you. I'm sorry if it seems like
that for you.
It was an intermediate review with several points to be clear for _me_
from experienced hackers, mostly about a code design.
26.01.2016 07:05, Pavel Stehule пишет:
>> pg_proc.h has changed, so the
d6a57e1a61d5bf756349e8
[3]http://www.postgresql.org/docs/devel/static/functions-admin.html#FUNCTIONS-ADMIN-BACKUP-TABLE
[4]https://en.wikipedia.org/wiki/Binary_prefix#Adoption_by_IEC.2C_NIST_and_ISO
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2/15/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> P.S.: "bytes" size unit was added just for consistency: each group
> should have a name, even with an exponent of 1.
Oops... Of course, "even with an exponent of 0".
--
Best regards,
Vitaly Buro
more
> readable to just parse the supported units directly in
> pg_size_bytes(), rather than trying to share code with guc.c, when the
> supported units are actually different and may well diverge further in
> the future.
>
> I'll try to hack something up, and see what it looks like.
>
> Regards,
> Dean
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2/16/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> On 2/16/16, Dean Rasheed <dean.a.rash...@gmail.com> wrote:
>> On 16 February 2016 at 05:01, Pavel Stehule <pavel.steh...@gmail.com>
>> wrote:
>>> 2016-02-15 10:16 GMT+01:00 Dean Ras
On 2/16/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> On 2/16/16, Dean Rasheed <dean.a.rash...@gmail.com> wrote:
>> Fixing that in parse_memory_unit() would be messy because it assumes a
>> base unit of kB, so it would require a negative multiplier, and
&g
On 2/17/16, Dean Rasheed <dean.a.rash...@gmail.com> wrote:
> On 17 February 2016 at 00:39, Vitaly Burovoy <vitaly.buro...@gmail.com>
> wrote:
>> Now parse_memory_unit returns -1024 for bytes as divider, constant
>> "bytes" has moved there.
>> Add
_DAY are one of them.
I would leave it as is.
> The #defines would be less brittle in
> the event, for example, that the postgres epoch were ever changed.
I don't think it is real, and even in such case all constants are
collected together in the file and will be found and changed at once.
&
On 3/14/16, Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote:
> 14.03.2016 16:23, David Steele:
>> On 2/25/16 4:44 PM, Vitaly Burovoy wrote:
>>
>>> Added to the commitfest 2016-03.
>>>
>>> [CF] https://commitfest.postgresql.org/9/540/
>
uch of the actual problem could be addressed by teaching make_date()
> and friends to accept negative year values as meaning BC.
>
> regards, tom lane
Thank Thomas, Robert and Tom very much for an interesting (but short)
discussion.
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2016-03-15, David Steele <da...@pgmasters.net> wrote:
> On 3/4/16 2:56 PM, Vitaly Burovoy wrote:
>> On 3/4/16, Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote:
>>
>>> I think that you should update documentation. At least description
On 3/11/16, Robert Haas <robertmh...@gmail.com> wrote:
> On Sun, Feb 28, 2016 at 9:38 PM, Vitaly Burovoy
> <vitaly.buro...@gmail.com> wrote:
>>> However, I'm not sure we ought to tinker with the behavior in this
>>> area. If -MM-DD is going to accept things
ect, so I
have no idea why "before ? JB_PATH_INSERT_BEFORE :
JB_PATH_INSERT_AFTER" works.
I think either proper comment should be added or lack in the code must be found.
Anyway the variable's name must reflect the SQL argument's name.
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 3/29/16, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Pushed with minor adjustments.
>
> regards, tom lane
>
Thank you very much!
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
e JULIAN_MINDAY and JULIAN_MAXDAY which are
not used now?
Also why JULIAN_MAXMONTH is set to "6" whereas
{DATE|TIMESTAMP}_END_JULIAN use "1" as month?
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2016-03-23, Oleg Bartunov <obartu...@gmail.com> wrote:
> On Wed, Mar 23, 2016 at 6:37 AM, Vitaly Burovoy <vitaly.buro...@gmail.com>
> wrote:
>
>> Hello, Hackers!
>>
>> While I was reviewed a patch with "json_insert" function I found a bug
>&g
te about importance of
existing intermediate keys. Try to reword it since the function
doesn't have a "create_missing" parameter support.
> All the items of the path parameter of jsonb_set must be present in the
> target,
> ... in which case all but the last item must be present.
Currently I can't break the code, so I think it is close to the final state. ;-)
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
posed patch in an attachment fixes it.
There is a magic number "20" as a length of an array for copying key
from a path before passing it to strtol. It is a maximal length of a
value which can be parsed by the function. I could not find a proper
constant for it. Also I found similar dire
On 2016-03-15, Mark Dilger <hornschnor...@gmail.com> wrote:
>
>> On Mar 14, 2016, at 5:12 PM, Vitaly Burovoy <vitaly.buro...@gmail.com>
>> wrote:
>>
>> On 3/14/16, Mark Dilger <hornschnor...@gmail.com> wrote:
>>> The first thing I no
rect if checks for IS_VALID_DATE is added in date.c to
places marked as "IS_VALID_JULIAN is enough for checking..."
All other places are (I'm sure) covered by IS_VALID_DATE/IS_VALID_TIMESTAMP.
What about the question:
On 2016-02-24, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> A
column threshold...
The same rules for the documentation.
9. And finally... it does not work as expected in case of:
postgres=# select jsonb_insert('{"a":[0,1,2,3]}', '{"a", 10}', '"4"');
jsonb_insert
-
{"a": [0, 1, 2, 3]}
(1 row)
wheras jsonb_set
On 3/4/16, Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote:
> 27.02.2016 09:57, Vitaly Burovoy:
>> Hello, Hackers!
>>
>> I worked on a patch[1] allows "EXTRACT(epoch FROM
>> +-Inf::timestamp[tz])" to return "+-Inf::float8".
>>
committers, it can end up as "Rejected with feedback" (since the patch
is already in the CF[1])?
[1]https://commitfest.postgresql.org/9/485/
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2/26/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> Proposed patch implements it.
I'm sorry, I forgot to leave a note for reviewers and committers:
This patch requires CATALOG_VERSION_NO be bumped.
Since pg_proc.h entry has changed, it is important to check and run
regr
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
I have reviewed this patch.
It applies cleanly at the top of
On 3/30/16, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> On 31 March 2016 at 05:04, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
>> The documentation changes still has to be fixed.
> Thanks for help. Looks like I'm not so good at text formulation. Fixed.
Never mi
mjian <br...@momjian.us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
I'd vote for 9.6 up to 9.9 then 10.0…
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.X 15.X
...
10.6.X 19.X
10.7.X 20.X
10.8.X 21.X
10.9.X 22.X
11.0.X 23.X
11.1.X 24.X
Etc.
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I'm sorry for the late answer.
On 4/27/16, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
> Vitaly Burovoy wrote:
>
> Hi,
>
>> But before starting working on it I had a look at the SQL-2011
>> standard (ISO/IEC 9075-2)[3] and found that:
>>
>> 1. A name
sage-id/2723429.ZaCixaFn1x@dinodell
[2]
http://www.postgresql.org/message-id/dd701b62-008d-4048-882e-20df0e4b5...@postgrespro.ru
[3]
http://www.postgresql.org/message-id/caezatcxhz5ggfrfcf9_yw5h6wdxr68qdfiwhvmgfr3ascnq...@mail.gmail.com
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hacke
On 5/3/16, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Vitaly Burovoy <vitaly.buro...@gmail.com> writes:
>> On 4/27/16, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
>>> Point 2 is where things differ from what I remember; my (possibly
>>> flawed) underst
ERE id = 4;
This query would return *TWO* records: ...
And it affected slaves, not master.
Slaves are for decreasing loading to master, if you run all queries
(even) RO at master, why would you (or someone) have so many slaves?
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hac
hould bump catversion. It is not bumped in the patch
because it is unclear when it is committed.
[1]https://postgr.es/m/CAJrrPGeT8zrGPMcRVk_wRvYD-ETcgUz6WRrc2C=inubmrkr...@mail.gmail.com
[2]http://standards.ieee.org/develop/regauth/tut/eui64.pdf
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hacke
ac->h);
In this case the left-hand side argument for the "*=" operator is
computed at the compile time as a single constant.
The second line can be written as "res *= 256. * 256 * 256 * 256;"
(pay attention to a dot in the first multiplier), but it is not
readable at all (a
/backend/utils/adt/network.c
pg_indent makes it uglier. I've just found how to write the line for it:
res *= ((double) 256) * 256 * 256 * 256;
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 1/25/17, Haribabu Kommi <kommi.harib...@gmail.com> wrote:
> On Wed, Jan 25, 2017 at 6:43 PM, Vitaly Burovoy <vitaly.buro...@gmail.com>
> wrote:
>
>> On 1/23/17, Haribabu Kommi <kommi.harib...@gmail.com> wrote:
>> > The patch is split into two parts
uot;)?
6. In ATExecDropIdentity: is it a good idea to do nothing if the
column is already not a identity (the same behavior as DROP NOT
NULL/DROP DEFAULT)?
7. Is there any reason to insert CREATE_TABLE_LIKE_IDENTITY before
CREATE_TABLE_LIKE_INDEXES, not at the end?
Why do you change catversio
On 9/11/16, Kevin Grittner <kgri...@gmail.com> wrote:
> On Sat, Sep 10, 2016 at 12:26 AM, Vitaly Burovoy
>> Mark it as "Ready for committer".
>>
>> P.S.: While I was reviewing I simplified SQL query: improved version
>> only 2 seqscans instead of 3 seqsca
On 9/11/16, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Vitaly Burovoy <vitaly.buro...@gmail.com> writes:
>> On 9/11/16, Kevin Grittner <kgri...@gmail.com> wrote:
>>> I was able to find cases during test which were not handled
>>> correctly with either versi
| en_US.UTF-8 | en_US.UTF-8 |
db2 | bob | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
(2 rows)
postgres=# set role bob;
SET
postgres=> CREATE DATABASE ss TEMPLATE db -- shows both
db1 db2
postgres=> CREATE DATABASE ss TEMPLATE db2;
ERROR: permission denied to create database
postgres=>
So a check for the CREATEDB privilege should be done at the point
whether to show CREATE DATABASE or not.
But if a user has privileges, Tom's version works fine.
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ect, Blue Treble Consulting, Austin TX
Hex or base64 are not data types. They are just different
representation types of binary sequences.
Even for bigints these representations are done after writing numbers
as byte sequences.
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers
On 9/12/16, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote:
> Thank you for this extensive testing. I will work on getting the bugs
> fixed. Just a couple of comments on some of your points:
>
> On 9/9/16 11:45 PM, Vitaly Burovoy wrote:
>> It compiles and p
/create_table.sgml (5th chunk) has "TODO". Why?
---
14. It would be fine if psql has support of new clauses.
===
Also several notes:
15. Initializing attidentity in most places is ' ' but makefuncs.c has
"n->identity = 0;". Is it correct?
---
16. I think it is a good idea to
to all supported versions.
No documentation needed.
Mark it as "Ready for committer".
P.S.: While I was reviewing I simplified SQL query: improved version
only 2 seqscans instead of 3 seqscans with an inner loop in an
original one.
Please find a file "tab-complete-create-database-
For restoring to stdout (or dumping to a plain SQL file) I left
current behavior: all options in the SET block are written.
Also I left "SET row_security = on;" if "enable_row_security" is set
to break restoring to a DB non-supported version.
--
Best regards,
Vitaly Burovoy
d
On 10/5/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> On 10/5/16, Andres Freund <and...@anarazel.de> wrote:
>> On 2016-10-05 15:23:05 -0700, Vitaly Burovoy wrote:
>>> On 10/5/16, Andres Freund <and...@anarazel.de> wrote:
>>> > On 2016-10-05
gt;> the
>> default in effect at the time the column was added can never change, no
>> matter what you do to the default later on.
>
> DROP DEFAULT pretty much does that, because it allows multiple (set of)
> rows with no value (or a NULL) for a specific column, but with differing
table (pg_attribute) as default column values of
the "pre-alter" era. It solves changing of the default expression of
the same column later.
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
;
SELECT * FROM t ORDER BY pk;
ALTER TABLE t ADD COLUMN c2 serial;
SELECT * FROM t ORDER BY pk;
INSERT INTO t(pk) VALUES (4);
SELECT * FROM t ORDER BY pk;
P.S.: I really think it is a good idea, just some research is
necessary and covering corner cases...
--
Best regards,
Vitaly Burovoy
--
Sent vi
On 10/5/16, Andres Freund <and...@anarazel.de> wrote:
> On 2016-10-05 15:23:05 -0700, Vitaly Burovoy wrote:
>> On 10/5/16, Andres Freund <and...@anarazel.de> wrote:
>> > On 2016-10-05 11:58:33 -0700, Serge Rielau wrote:
>> >> Dear Hackers,
>> >
is recommended), but for a
separate table it is 11 columns with two indexes now...
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/5/16, Serge Rielau <se...@rielau.com> wrote:
>On Wed, Oct 5, 2016 at 4:19 PM, Vitaly Burovoy <vitaly.buro...@gmail.com>
>wrote:
>> But what I discover for myself is that we have pg_attrdef separately
>> from the pg_attribute. Why?
>> Is it time to j
onnected to the referenced row (by
referencing column list).
Also your proposal is not consistent: ON UPDATE REMOVE (DELETE?), but
ON DELETE - what? again remove/delete?
[1] https://wiki.postgresql.org/wiki/Mailing_Lists#Using_the_discussion_lists
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
up with a NULL.
As for me the best phrase is "pre-add-column-default", but it is
impossible to use it as a column name. :-(
It is still an open question.
(I remember funny versions in a discussion[1] when people tried to
choose a name for a function reversed to pg_size_pretty...)
[1
On 10/6/16, Serge Rielau <se...@rielau.com> wrote:
>> On Oct 6, 2016, at 9:20 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Vitaly Burovoy <vitaly.buro...@gmail.com> writes:
>>> But what I discover for myself is that we have pg_attrdef separately
>>> f
for
> itself once I have the WIP patch ready so we have something concrete to
> discuss
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/6/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> Ough. I made a mistake about pg_attribute because I forgot about the
> pg_attrdef.
> If we do not merge these tables, the pg_attrdef is the best place to
> store evaluated expression as a constant the same way def
Hello, hackers,
I've just noticed an extra word in a sentence in the docs in the
"parallel.sgml".
It seems the sentence was constructed one way and changed later with
the extra word left.
Please, find the fix attached.
--
Best regards,
Vitaly Burovoy
pg-docs-fix.patch
Descripti
1 - 100 of 143 matches
Mail list logo
