along with your fix.
>
> regards, tom lane
>
Oops. I missed it in "describe.c" because I grepped for exact "::name" string.
Thank you very much!
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 10/31/17, Tom Lane wrote:
> Vitaly Burovoy writes:
>> Recently my colleagues found a bug.
>
>> - "SELECT 'bigint'::name AS
>> sequence_type, "
>> + &quo
: [archiver (db)] query was: SELECT 'bigint'::name AS
sequence_type, start_value, increment_by, max_value, min_value,
cache_value, is_cycled FROM name_id_seq
I've implemented a little fix (attached), don't think there is
something to be written to docs and tests.
--
Best regards,
On 4/23/17, Robert Haas wrote:
> On Thu, Apr 20, 2017 at 12:05 AM, Vitaly Burovoy
> wrote:
>> OK. Let's go through it again.
>> IDENTITY is a property of a column. There are no syntax to change any
>> property of any DB object via the "ADD" syntax.
>
On 4/18/17, Peter Eisentraut wrote:
> On 4/7/17 01:26, Vitaly Burovoy wrote:
>> I've implement SET GENERATED ... IF NOT EXISTS. It must be placed
>> before other SET options but fortunately it conforms with the
>> standard.
>> Since that form always changes t
On 4/4/17, Peter Eisentraut wrote:
> On 3/30/17 22:47, Vitaly Burovoy wrote:
>> It seemed not very hard to fix it.
>> Please find attached patch to be applied on top of your one.
>>
>> I've added more tests to cover different cases of changing bounds when
>&g
On 4/6/17, Vitaly Burovoy wrote:
> On 4/6/17, Peter Eisentraut wrote:
>> As I tried to mention earlier, it is very difficult to implement the IF
>> NOT EXISTS behavior here, because we need to run the commands the create
>> the sequence before we know whether we will need
On 4/6/17, Peter Eisentraut wrote:
> On 4/4/17 22:53, Vitaly Burovoy wrote:
>> The next nitpickings to the last patch. I try to get places with
>> lacking of variables' initialization.
>> All other things seem good for me now. I'll continue to review the
>>
On 4/4/17, Vitaly Burovoy wrote:
> On 4/3/17, Peter Eisentraut wrote:
>> On 3/30/17 22:57, Vitaly Burovoy wrote:
>>> Why do you still want to leave "ADD IF NOT EXISTS" instead of using
>>> "SET IF NOT EXISTS"?
>>> If someone wants to
On 4/3/17, Peter Eisentraut wrote:
> On 3/30/17 22:57, Vitaly Burovoy wrote:
>> Why do you still want to leave "ADD IF NOT EXISTS" instead of using
>> "SET IF NOT EXISTS"?
>> If someone wants to follow the standard he can simply not to use "IF
>
On 3/29/17, Peter Eisentraut wrote:
> On 3/24/17 05:29, Vitaly Burovoy wrote:
>> It would be great if "DROP IDENTITY IF EXISTS" is in the current patch
>> since we don't have any disagreements about "DROP IDENTITY" behavior
>> and easiness of imple
On 3/30/17, Vitaly Burovoy wrote:
> On 3/29/17, Vitaly Burovoy wrote:
>> On 3/29/17, Michael Paquier wrote:
>>> On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy
>>> wrote:
>>>> I think min_value and max_value should not be set to "1" or &qu
On 3/30/17, Vitaly Burovoy wrote:
> On 3/29/17, Vitaly Burovoy wrote:
>> On 3/29/17, Michael Paquier wrote:
>>> On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy
>>> wrote:
>>>> I think min_value and max_value should not be set to "1" or &qu
On 3/29/17, Vitaly Burovoy wrote:
> On 3/29/17, Michael Paquier wrote:
>> On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy
>> wrote:
>>> I think min_value and max_value should not be set to "1" or "-1" but
>>> to real min/max of the type by
On 3/29/17, Michael Paquier wrote:
> On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy
> wrote:
>> I think min_value and max_value should not be set to "1" or "-1" but
>> to real min/max of the type by default.
>
> This is the default behavior for ages
NO MAXVALUE INCREMENT 1;
ALTER SEQUENCE sequence_test11 AS int NO MINVALUE NO MAXVALUE INCREMENT -1;
--
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/23/17, Peter Eisentraut wrote:
> On 3/23/17 06:09, Vitaly Burovoy wrote:
>> I think we'll end up with "DROP IDENTITY IF EXISTS" to avoid raising
>> an exception and "ADD OR SET" if your grammar remains.
>
> That sounds reasonable to me.
It wou
On 3/22/17, Peter Eisentraut wrote:
> On 3/22/17 03:59, Vitaly Burovoy wrote:
>> Column's IDENTITY behavior is very similar to a DEFAULT one. We write
>> "SET DEFAULT" and don't care whether it was set before or not, because
>> we can't have many of t
On 3/21/17, Peter Eisentraut wrote:
> On 3/21/17 16:11, Vitaly Burovoy wrote:
>> My argument is consistency.
>> Since IDENTITY is a property of a column (similar to DEFAULT, NOT
>> NULL, attributes, STORAGE, etc.), it follows a different rule: it is
>> either set or
7; bad experience who will know nothing
about sequences (because they'll deal with identity columns).
Would it be better to change bounds of a sequence if they match the
bounds of an old type (to the bounds of a new type)?
> --
> Peter Eisentraut http://www.2ndQuadrant.com/
On 2/28/17, Peter Eisentraut wrote:
> New patch that fixes everything. ;-)
Great work!
> On 1/4/17 19:34, Vitaly Burovoy wrote:
>> 1. The fact COPY ignores GENERATED ALWAYS constraint (treats as
>> GENERATED BY DEFAULT) should be mentioned as well as rules.
>
> fi
On 3/15/17, Peter Eisentraut wrote:
> Vitaly, will you be able to review this again?
>
> --
> Peter Eisentraut http://www.2ndQuadrant.com/
I apologize for a delay. Yes, I'm going to do it by Sunday.
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers ma
ter should 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-
k.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 wrote:
> On Wed, Jan 25, 2017 at 6:43 PM, Vitaly Burovoy
> wrote:
>
>> On 1/23/17, Haribabu Kommi wrote:
>> > The patch is split into two parts.
>> > 1. Macaddr8 datatype support
>> > 2. Contrib module support.
>>
>&
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 (and produces the same code).
--
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
2] because source and
destination are not signed).
Moreover you've already fill in "hibits" the topmost byte by shifting by 24.
If you use those two macros ("hibits" and "lobits") it allows to avoid
two extra comparisons in macaddr8_cmp_internal.
Version from the "macaddr64_poc.patch" is correct.
[1]https://www.postgresql.org/message-id/CAKOSWNng9_+=fvo6oz4tgv1kkhmom11ankihbokpuzki1ca...@mail.gmail.com
[2]http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1817.htm
--
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/5/17, Tom Lane wrote:
> Vitaly Burovoy writes:
>> On 1/5/17, Tom Lane wrote:
>>> My point is that ideally, any value that can physically fit into struct
>>> Interval ought to be considered valid. The fact that interval_out can't
>>> cope is a bu
On 1/5/17, Tom Lane wrote:
> Vitaly Burovoy writes:
>> On 1/5/17, Tom Lane wrote:
>>> We could think about replacing interval2tm's output format with some
>>> other struct that uses a TimeOffset for hours and so cannot overflow.
>>> I'm not sure
On 1/5/17, Tom Lane wrote:
> Vitaly Burovoy writes:
>>> I've written a patch which fixes that bug (in attachment).
>>> Should it be registered in the CF?
>
>> Oops. Forgot to attach the patch. Fixed.
>
> I suspect that many of these SAMESIGN() tests
On 1/5/17, Vitaly Burovoy wrote:
> On 1/4/17, Pantelis Theodosiou wrote:
>> On Wed, Jan 4, 2017 at 3:03 PM, wrote:
>>
>>> The following bug has been logged on the website:
>>>
>>> Bug reference: 14486
>>> Logged by: Per Mo
t col from xx where col < interval '10 year' ;
> col
> -
> (0 rows)
>
Yes, it is a bug, but it is not a constraint, it is just different
internal checks.
Moreover even if a function does not raise an error, output could be wrong
(pay attention to the duplicated '-'
"idnt" is an identity column
15. And finally. The command:
test=# CREATE TABLE t(i int GENERATED BY DEFAULT AS IDENTITY (SEQUENCE NAME s));
leads to a core dump.
It happens when no sequence parameter (like "START") is set.
[1]https://www.postgresql.org/docs/devel/static/sql-createtable.html
--
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/12/16, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> Vitaly Burovoy writes:
>>>> P.S.: I still think it is a good idea to change storage format,
>>> I'm not sure which part of "no" you didn't understand,
I j
On 10/12/16, Tom Lane wrote:
> Vitaly Burovoy writes:
>> I'm sorry for the offtopic, but does anyone know a reason why a
>> condition in mac.c
>
>>> if ((a < 0) || (a > 255) || (b < 0) || (b > 255) ||
>>> (c < 0) || (c > 255) || (d
an not be rewritten as:
> if (((a | b | c | d | e | f) < 0) ||
> ((a | b | c | d | e | f) > 255))
It seems more compact and a compiler can optimize it to keep a result
of a binary OR for the comparison with 255...
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers maili
On 10/12/16, Vitaly Burovoy wrote:
> On 10/12/16, Alvaro Herrera wrote:
>> Julien Rouhaud wrote:
>>> On 12/10/2016 14:32, Alvaro Herrera wrote:
>>> > Julien Rouhaud wrote:
>>> >
>>> >> and you can instead make macaddr64 support
type macaddr. Right?
>
> (The cast function from macaddr8 to macaddr would raise error if the
> 4th and 5th bytes are not either FF:FF or FF:FE -- I don't think we can
> in practice distinguish EUI-48 from MAC-48 in this context.
The wikipedia says[1] they are the same things but
On 10/6/16, Serge Rielau wrote:
>> On Oct 6, 2016, at 9:20 AM, Tom Lane wrote:
>> Vitaly Burovoy writes:
>>> But what I discover for myself is that we have pg_attrdef separately
>>> from the pg_attribute. Why?
>>
>> The core reason for that is th
On 10/6/16, Vitaly Burovoy 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 defaults are
> stored in adbin.
Oo
"ALTER COLUMN ... TYPE ... USING"
> and evaluate that when we build the tuple descriptor.
> This happens when we load the relation into the relcache.
>
> Anyway, I’m jumping ahead and it’s perhaps best to let the code speak for
> itself once I have the WIP patch ready so
On 10/6/16, Tom Lane wrote:
> Serge Rielau writes:
>>> On Oct 6, 2016, at 5:25 AM, Vitaly Burovoy
>>> wrote:
>>>> Which makes me think we should call this missing_value or absent_value
Be honest Simon Rigg's wrote that words.
>>>> so its clear
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]
https://www.postgresql.org/mess
On 10/5/16, Serge Rielau wrote:
>On Wed, Oct 5, 2016 at 4:19 PM, Vitaly Burovoy
>wrote:
>> But what I discover for myself is that we have pg_attrdef separately
>> from the pg_attribute. Why?
>> Is it time to join them? For not presented defaults it would be only
>&g
d), 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
ect 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
> applicable default values.
DROP DE
On 10/5/16, Vitaly Burovoy wrote:
> On 10/5/16, Andres Freund wrote:
>> On 2016-10-05 15:23:05 -0700, Vitaly Burovoy wrote:
>>> On 10/5/16, Andres Freund wrote:
>>> > On 2016-10-05 11:58:33 -0700, Serge Rielau wrote:
>>> >> Dear Hackers,
>>&g
On 10/5/16, Andres Freund wrote:
> On 2016-10-05 15:23:05 -0700, Vitaly Burovoy wrote:
>> On 10/5/16, Andres Freund wrote:
>> > On 2016-10-05 11:58:33 -0700, Serge Rielau wrote:
>> >> Dear Hackers,
>> >> I’m working on a patch that expands PG
ute) 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
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 via pgsq
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
Desc
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
lly removing on update event is more
> rational.
I personally don't see necessity to introduce new non-spec grammar.
If you think I has not understood you, send an example with schema ---
what you have now and how you expect it should be.
--
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/2/16, Michael Paquier wrote:
> On Mon, Oct 3, 2016 at 3:25 PM, Vitaly Burovoy
> wrote:
>> I guess for ability to use filtering like:
>>
>> SELECT * FROM pg_hba_rules WHERE options->>radiusserver LIKE
>> '%.example.com';
>>
>> I
RE options->>radiusserver LIKE '%.example.com';
I think it would be harder if options is an array of strings...
--
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
ple patches in a
commitfest to be familiar with the process.
--
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 9/27/16, Vitaly Burovoy wrote:
> On 9/27/16, Tom Lane wrote:
>> (The other thing I'd want here is a --target-version option so that
>> you could get the same output alterations in pg_dump or pg_restore to
>> text. Otherwise it's nigh undebuggable, and certainly
On 9/27/16, Tom Lane wrote:
> Vitaly Burovoy writes:
>> On 9/27/16, Tom Lane wrote:
>>> I'm not exactly convinced that you did. There's only one copy of
>>> Archive->remoteVersion, and you're overwriting it long before the
>>> dump proces
On 9/27/16, Tom Lane wrote:
> Vitaly Burovoy writes:
>> On 9/27/16, Tom Lane wrote:
>>> The general policy has always been that pg_dump output is only expected
>>> to
>>> restore without errors into a server that's the same or newer version as
>>&g
On 9/27/16, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Sep 26, 2016 at 9:56 PM, Vitaly Burovoy
>> wrote:
>>> We do dump/restore schemas/data via custom/dir formats and we have to
>>> keep several client versions for 9.2, 9.4 and 9.5 versions on loc
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 9/12/16, Peter Eisentraut 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 passes "make check" tests, but fai
-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
On 9/11/16, Tom Lane wrote:
> Vitaly Burovoy writes:
>> On 9/11/16, Kevin Grittner wrote:
>>> I was able to find cases during test which were not handled
>>> correctly with either version, so I tweaked the query a little.
>
>> Hmm. Which one? Attempt to &q
On 9/11/16, Kevin Grittner 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 seqscans with an inner loop in
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 mailing list (pgsql-hackers@postgresql.or
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-
7;, 2, true);
---
13. doc/src/sgml/ref/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
t; ")?
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 catversion
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-hackers mailing list (pgsql-hackers@pos
On 6/15/16, Michael Paquier wrote:
> On Thu, Jun 16, 2016 at 12:10 PM, Vitaly Burovoy
> wrote:
>> In the initial letter[1] I posted a digest from the SQL-2011 standard
>> and a conclusion as a design of a new patch.
>> Now I have more free time and I'm hacking it tha
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/attachment/41886/catalog-notnul
eSQL 95),
current beta not 9.6 but 96 etc, but just divided by 10.
In fact it is similar to Tom's offer but avoided proposed bump to 10.0
and left increasing by 0.1 instead of 1.0:
curnt Tom's proposed
9.5.X 9.5.X
9.6.X 9.6.X
9.7.X 10.X
9.8.X 11.X
9.9.X 12.X
10.0.X 13.X
10.1.X 14.
evelopers and
near-zero-downtime is mostly for system administrators/DBA.
> I think the fundamental issue is whether we want to lead the 10.0 branch
> with parallelism, or wait for an administrative change like
> near-zero-downtime major upgrades and built-in logical replication.
>
> Bru
Fn1x@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-hackers mailing list (pgsql-hac
On 5/3/16, Tom Lane wrote:
> Vitaly Burovoy writes:
>> On 4/27/16, Alvaro Herrera wrote:
>>> Point 2 is where things differ from what I remember; my (possibly
>>> flawed) understanding was that there's no difference between those
>>> things. Many (ma
I'm sorry for the late answer.
On 4/27/16, Alvaro Herrera 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 for a "NOT NULL"
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 curr
On 3/30/16, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> On 31 March 2016 at 05:04, Vitaly Burovoy wrote:
>> The documentation changes still has to be fixed.
> Thanks for help. Looks like I'm not so good at text formulation. Fixed.
Never mind. I'm also not so good
On 3/29/16, Tom Lane 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 your subscr
r it seems the logic in the code is correct, 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 2016-03-23, Oleg Bartunov wrote:
> On Wed, Mar 23, 2016 at 6:37 AM, Vitaly Burovoy
> wrote:
>
>> Hello, Hackers!
>>
>> While I was reviewed a patch with "json_insert" function I found a bug
>> which wasn't connected with the patch and reprodu
string number length is not a multiplier of 4 rest bytes
are padding by '\0', when length is a multiplier of 4 there is no
padding, just garbage after the last digit of the value.
Proposed patch in an attachment fixes it.
There is a magic number "20" as a length of an array f
.
The documentation: add "jsonb_insert" to the note 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
o I'm asking for a help because the query (in default TZ='GMT+1'):
> postgres=# SELECT '4714-11-24 00:00:00.00+00 BC'::timestamptz;
>
> in psql gives a result "4714-11-23 23:00:00-01 BC",
> but in a testing system gives "Sun Nov 23 23:00:00 4714
On 2016-03-15, Mark Dilger wrote:
>
>> On Mar 14, 2016, at 5:12 PM, Vitaly Burovoy
>> wrote:
>>
>> On 3/14/16, Mark Dilger wrote:
>>> The first thing I notice about this patch is that
>>> src/include/datatype/timestamp.h
>>> has some
AXDAY 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-15, David Steele wrote:
> On 3/4/16 2:56 PM, Vitaly Burovoy wrote:
>> On 3/4/16, Anastasia Lubennikova wrote:
>>
>>> I think that you should update documentation. At least description of
>>> epoch on this page:
>>> http://www.postgresql.org
On 3/14/16, Anastasia Lubennikova 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/
>>
>> This looks like a fai
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.
&
th of them support ones).
> but I wonder how
> much 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 3/11/16, Robert Haas wrote:
> On Sun, Feb 28, 2016 at 9:38 PM, Vitaly Burovoy
> wrote:
>>> However, I'm not sure we ought to tinker with the behavior in this
>>> area. If -MM-DD is going to accept things that are not of the
>>> format -MM-DD,
olumn 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": [
On 3/4/16, Anastasia Lubennikova 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".
>> There is an opposite function &quo
On 2/26/16, Vitaly Burovoy 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
regress tests on a new cluste
p 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
# select to_date('0001-06-01 BC', '-MM-DD BC');
> to_date
> ---
> 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
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
sql.org/wiki/Todo#Dates_and_Times
[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
Thomas Munro) I know the patch is not
ready for committing even with minimal changes. But I'm waiting for a
discussion: what part should be changed?
I would change behavior of "to_date" and "to_timestamp" to match with
extract options "year"/"isoyear"
1 - 100 of 143 matches
Mail list logo
