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"
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
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
# 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
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
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
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
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/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,
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
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 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
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
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, 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
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
.
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
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
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
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 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
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 hone
On 1/14/16, Tom Lane wrote:
> Vitaly Burovoy writes:
>> On 1/14/16, Tom Lane wrote:
>>> It's more than syntactic sugar; you are going to have to invent
>>> semantics,
>>> as well, because it's less than clear what partial-field assignments
>>&
y?
>
> 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?
-
; ...
>
> --
> 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
ot;
---
+ 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" whereas the others are not.
Note:
"The behavior is undefined if the value of ch is not representable as
unsigned char and is not equal to EOF"
Proof:
http://en.cppreference.com/w/c/string/byte/isspace
---
+ pfree(buffer);
+ pfree(str);
pfree-s here are not necessary. See:
http://www.neilconway.org/talks/hacking/hack_slides.pdf (page 17)
--
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/18/16, Vitaly Burovoy wrote:
> <>
> ---
> + if (*strptr != '\0')
> ...
> + while (*strptr && !isspace(*strptr))
> Sometimes it explicitly compares to '\0', sometimes implicitly.
> Common use is explicit comparison
On 1/20/16, Pavel Stehule 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 to your subscription:
uot;str" allocated 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...@
us-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 via pgsql-hackers mailing list (pgsql-hack
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 of
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 C
" 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 checking f
sage" 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 decrease performance. And then I have
6+00 | 9223372036855.78
294277-01-09 04:00:54.775806+00 | 9224318721654.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
two.
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 (pgsql-hackers@postgre
On 2/2/16, Tom Lane 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 writes:
>> I've just found a littl
On 2/7/16, Vitaly Burovoy 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] (in attachment). At least
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 Burovoy
pg-size-bytes-
/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
ad76f5f275ef2d6a57e1a61d5bf756349e8
[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 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 Burovoy
--
Sent via pgsql-hackers m
; a valid size unit even
in GUC by adding it to the memory_unit_conversion_table with
reflecting it in memory_units_hint and removing an extra checking from
pg_size_bytes.
> ISTM that it would be far less code, and much simpler and more
> readable to just parse the supported units directly
On 2/16/16, Vitaly Burovoy wrote:
> On 2/16/16, Dean Rasheed wrote:
>> On 16 February 2016 at 05:01, Pavel Stehule
>> wrote:
>>> 2016-02-15 10:16 GMT+01:00 Dean Rasheed :
>> Fixing that in parse_memory_unit() would be messy because it assumes a
>> base unit o
On 2/16/16, Vitaly Burovoy wrote:
> On 2/16/16, Dean Rasheed 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
>> pg_size_bytes() would have to be taught to divide by the mag
On 2/17/16, Dean Rasheed wrote:
> On 17 February 2016 at 00:39, Vitaly Burovoy
> wrote:
>> Now parse_memory_unit returns -1024 for bytes as divider, constant
>> "bytes" has moved there.
>> Add new memory_units_bytes_hint which differs from an original
>&g
iven. In such case era indicator is ignored (for me it is
obvious signs should be OR-ed):
postgres=# SELECT to_timestamp('-0010*01*01 BC', '*MM*DD BC')
postgres-# ,to_timestamp(' 0010*01*01 BC', '*MM*DD BC');
to_timestamp| to_timestamp
---
On 2/22/16, Vitaly Burovoy 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,
Vitaly Burovoy
--
Sent v
On 2/22/16, Thomas Munro wrote:
> On Tue, Feb 23, 2016 at 11:58 AM, Vitaly Burovoy
> wrote:
>> Hello, Hackers!
>>
>> I'm writing another patch and while I was trying to cover corner cases
>> I found that to_date and to_timestamp work wrong if year in
On 2/24/16, Vitaly Burovoy wrote:
> On 2/2/16, Jim Nasby 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 not accept years beyond, say, 10 AD.
>>> That wou
>
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
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
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
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-
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
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
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
-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/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
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/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
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:
> 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, 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
: [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 10/31/17, Tom Lane wrote:
> Vitaly Burovoy writes:
>> Recently my colleagues found a bug.
>
>> - "SELECT 'bigint'::name AS
>> sequence_type, "
>> + &quo
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/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
"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, 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
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
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/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
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, 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
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 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
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
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 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
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/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
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/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
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
1 - 100 of 143 matches
Mail list logo
