> 3. The value is logically defined as a 128-bit integer, that is in
> itself a compound value split into a few "bit groups". Extracting
> these parts can be done by simple (and supposedly efficient) bitwise
> operators when stored as integer, but becomes much more cumbersome
> with UUID, I guess.
On Wed, Oct 23, 2019 at 12:01 PM Stuart McGraw wrote:
> When examples are given, they typically are with scalar values where
> such behavior makes sense: the resulting scalar value has to be NULL
> or non-NULL, it can't be both.
>
> It is less sensible with compound values where the rule can appl
Hello,
On Wed, 2019-10-23 at 20:33 +0200, Peter J. Holzer wrote:
>
> I grant that SQL NULL takes a bit to get used to. However, it is a
> core
> part of the SQL language and everyone who uses SQL must understand it
> (I
> don't remember when I first stumbled across "select * from t where c
> =
>
On Wed, Oct 23, 2019 at 12:01 PM Stuart McGraw wrote:
> Why the inconsistency between the array
> type and json type? Are there any cases other than json where the entire
> compound value is set to NULL as a result of one of its components being
> NULL?
That's a great point. It does look like hs
That's an absolutely reasonable suggestion. I am still in the exploration phase
so while this solution is not completely ruled out, I have some concerns about
it:
1.
Although it does not enforce, but the UUID type kind of suggests a specific
interpretation of the data. Of course the documenta
On 10/23/19 3:24 PM, Laiszner Tamás wrote:
That's an absolutely reasonable suggestion. I am still in the
exploration phase so while this solution is not completely ruled out,
I have some concerns about it:
1.
Although it does not enforce, but the UUID type kind of suggests a
specific
> On Oct 23, 2019, at 1:32 PM, Laiszner Tamás wrote:
>
> Hey there,
>
> I am currently exploring the options to utilize 128-bit numeric primary keys.
> One of the options I am looking at is to store them as composites of two
> 64-bit integers.
>
> The documentation page on composite types d
Hey there,
I am currently exploring the options to utilize 128-bit numeric primary keys.
One of the options I am looking at is to store them as composites of two 64-bit
integers.
The documentation page on composite types does not tell too much about the
internal storage, so I've made my own ex
So reading responses from all, here is a SQL test I did on few RDBMS:
select 'John'
'Doe' as rrr
from information_schema.tables
limit 1;
PG output
rrr
---
JohnDoe
Oracle and mysql gave same output as PG with no error
SQLServer: Syntax error near 'as'.
DB2 gave same error as SQLServ
Hi!
Bump my previous question. I find it surprising that it seems this
information is not possible to be reconstructed by the client, when
the server has to have it internally. Is this a new feature request or
am I missing something?
> I am trying to understand how could I automatically parse an
On Wed, Oct 23, 2019 at 9:03 PM Peter J. Holzer wrote:
>
> On 2019-10-23 17:20:07 +0100, Geoff Winkless wrote:
> > For what it's worth, I can see a value to having
> >
> > SELECT 'this is quite a long string'
> >'which I've joined together '
> >'across multiple line
On Wed, Oct 23, 2019 at 5:55 PM Ron wrote:
> No doubt: it's a bug, no matter what the Pg devs say.
select 'a'
'b' = 'ab'
this is what SQL mandates
You should submit a complain to SQL guys
--
cpp-today.blogspot.com
On 2019-10-23 17:20:07 +0100, Geoff Winkless wrote:
> For what it's worth, I can see a value to having
>
> SELECT 'this is quite a long string'
>'which I've joined together '
>'across multiple lines';
>
> although the advantage of it vs using a concat operator is s
On 10/23/19 5:42 AM, Laurenz Albe wrote:
David G. Johnston wrote:
Now if only the vast majority of users could have and keep this level of
understanding
in mind while writing complex queries so that they remember to always add
protections
to compensate for the unique design decision that SQL h
On 10/23/19 11:20 AM, Geoff Winkless wrote:
On Wed, 23 Oct 2019 at 17:09, Ron wrote:
As much as I hate to say it, MSFT was right to ignore this bug in the standard.
Standards are standards for a reason. It is almost never correct to
deliberately ignore them. If you don't like them, then revis
On 2019-10-22 18:06:39 -0700, David G. Johnston wrote:
> On Tue, Oct 22, 2019 at 3:55 PM Peter J. Holzer wrote:
> On 2019-10-20 13:20:23 -0700, Steven Pousty wrote:
> > I would think though that raising an exception is better than a
> > default behavior which deletes data.
> > As a
On 23/10/2019 17:30, Ron wrote:
On 10/23/19 11:27 AM, Geoff Winkless wrote:
On Wed, 23 Oct 2019 at 17:20, Geoff Winkless wrote:
For what it's worth, I can see a value to having
SELECT 'this is quite a long string'
'which I've joined together '
'across multiple
On 10/23/19 9:30 AM, Ron wrote:
On 10/23/19 11:27 AM, Geoff Winkless wrote:
On Wed, 23 Oct 2019 at 17:20, Geoff Winkless wrote:
For what it's worth, I can see a value to having
SELECT 'this is quite a long string'
'which I've joined together '
'across multiple
On 10/23/19 7:55 AM, Ravi Krishna wrote:
Surprisingly (to me), no….
db=# select to_date('20181501','MMDD');
to_date
2019-03-03
The above fails in 11.5 SQL Error [22008]: ERROR: date/time field value out of range:
"20181501"
Behavior changed in
On 10/23/19 11:27 AM, Geoff Winkless wrote:
On Wed, 23 Oct 2019 at 17:20, Geoff Winkless wrote:
For what it's worth, I can see a value to having
SELECT 'this is quite a long string'
'which I've joined together '
'across multiple lines';
although the advantage o
On Wed, 23 Oct 2019 at 17:20, Geoff Winkless wrote:
> For what it's worth, I can see a value to having
>
> SELECT 'this is quite a long string'
>'which I've joined together '
>'across multiple lines';
>
> although the advantage of it vs using a concat operator is sl
On 10/23/19 11:20 AM, Geoff Winkless wrote:
On Wed, 23 Oct 2019 at 17:09, Ron wrote:
As much as I hate to say it, MSFT was right to ignore this bug in the standard.
Standards are standards for a reason. It is almost never correct to
deliberately ignore them. If you don't like them, then revis
On Wed, 23 Oct 2019 at 17:09, Ron wrote:
> As much as I hate to say it, MSFT was right to ignore this bug in the
> standard.
Standards are standards for a reason. It is almost never correct to
deliberately ignore them. If you don't like them, then revise the
standard.
Historically Microsoft ig
Also, I noticed that in this plan, the root (again, an Aggregate) has 0
Temp Read Blocks, but two of its children (two of the ModifyTable nodes)
have non-zero Temp Read Blocks. Again, this contradicts the documentation,
as these costs are stated to be cumulative. Any ideas?
Thanks,
Maciek
On Wed, Oct 23, 2019 at 8:47 AM Chris Morris
wrote:
> The foreign table has a primary key. Ruby on Rails uses a system query to
> lookup what the primary key on the table is, but it's querying the local
> database, and not finding anything. In a schema dump of the local database,
> I don't see a
On 10/23/19 11:00 AM, Tom Lane wrote:
Ron writes:
On 10/23/19 10:51 AM, Geoff Winkless wrote:
Two string constants that are only separated by whitespace with at
least one newline are concatenated and effectively treated as if the
string had been written as one constant.
Then -- since the 'e'
On 10/23/19 11:03 AM, Geoff Winkless wrote:
On Wed, 23 Oct 2019 at 16:55, Ron wrote:
Then -- since the 'e' is separated from 'd' by a comma, the result should be
"4", not "3".
No doubt: it's a bug, no matter what the Pg devs say.
I'm confused why you consider that to be true. The count is che
On Wed, Oct 23, 2019 at 4:42 AM Laurenz Albe
wrote:
> David G. Johnston wrote:
> > Now if only the vast majority of users could have and keep this level of
> understanding
> > in mind while writing complex queries so that they remember to always
> add protections
> > to compensate for the unique
On Wed, 23 Oct 2019 at 16:55, Ron wrote:
> Then -- since the 'e' is separated from 'd' by a comma, the result should be
> "4", not "3".
>
> No doubt: it's a bug, no matter what the Pg devs say.
I'm confused why you consider that to be true. The count is checking
for columns containing the strings
On Wed, Oct 23, 2019 at 8:56 AM Ravi Krishna wrote:
> >
> > Simplify:
> >
> > select 'a'
> > db-# 'b';
> > ?column?
> > --
> > ab
> > (1 row)
> >
> > This is not a bug.
> >
> > https://www.postgresql.org/docs/9.2/sql-syntax-lexical.html
> >
> > Two string constants that are only separated
Ron writes:
> On 10/23/19 10:51 AM, Geoff Winkless wrote:
>> Two string constants that are only separated by whitespace with at
>> least one newline are concatenated and effectively treated as if the
>> string had been written as one constant.
> Then -- since the 'e' is separated from 'd' by a co
On 23/10/2019 16:55, Ron wrote:
On 10/23/19 10:51 AM, Geoff Winkless wrote:
On Wed, 23 Oct 2019 at 16:42, Ravi Krishna wrote:
select count(*) from bugtest where fld1 in ('a','b','c'
'd','e');
Note the missing comma after 'c'.
PG takes it a syntac
>
> Simplify:
>
> select 'a'
> db-# 'b';
> ?column?
> --
> ab
> (1 row)
>
> This is not a bug.
>
> https://www.postgresql.org/docs/9.2/sql-syntax-lexical.html
>
> Two string constants that are only separated by whitespace with at
> least one newline are concatenated and effectively tre
On 10/23/19 10:51 AM, Geoff Winkless wrote:
On Wed, 23 Oct 2019 at 16:42, Ravi Krishna wrote:
select count(*) from bugtest where fld1 in ('a','b','c'
'd','e');
Note the missing comma after 'c'.
PG takes it a syntactically right SQL and gives 3 as
On Wed, 23 Oct 2019 at 16:42, Ravi Krishna wrote:
> select count(*) from bugtest where fld1 in ('a','b','c'
> 'd','e');
>
> Note the missing comma after 'c'.
>
> PG takes it a syntactically right SQL and gives 3 as output.
>
> In SQLServer it errors out
Weird, but apparently not a bug. From
https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS
> Two string constants that are only separated by whitespace with at
> least one newline are concatenated and effectively treated as if the
> string had been written as one co
The foreign table has a primary key. Ruby on Rails uses a system query to
lookup what the primary key on the table is, but it's querying the local
database, and not finding anything. In a schema dump of the local database,
I don't see a primary key defined, so I'm presuming I need to issue an ADD
C
On 10/23/19 10:42 AM, Ravi Krishna wrote:
We noticed this bug in Redshift. It then occurred to me that this may
very well be a PG bug since Redshift is based on PG.
Reproduced it in Version 11.5
create table bugtest (fld1 char(1)) ;
insert into bugtest values('a');
insert into bugtest values('
We noticed this bug in Redshift. It then occurred to me that this may
very well be a PG bug since Redshift is based on PG.
Reproduced it in Version 11.5
create table bugtest (fld1 char(1)) ;
insert into bugtest values('a');
insert into bugtest values('b');
insert into bugtest values('c');
ins
Thank you -
On Mon, Oct 21, 2019 at 11:20 PM Adrian Klaver
wrote:
> As Thomas pointed there is a difference between -> and ->>:
>
> test_(postgres)# select pg_typeof('[{"one": 1, "two": 2}]'::jsonb -> 0
> -> 'one'), '[{"one": 1, "two": 2}]'::jsonb -> 0 -> 'one';
> pg_typeof | ?column?
> --
>
>
>
> Surprisingly (to me), no….
>
> db=# select to_date('20181501','MMDD');
> to_date
>
> 2019-03-03
The above fails in 11.5 SQL Error [22008]: ERROR: date/time field value out
of range: "20181501"
From: Ravi Krishna
> postgres=# select to_date('2018150X','MMDD');
> to_date
> 2019-03-03
> postgres=# select to_date('20181501','MMDD');
> to_date
>
> 2019-03-03
is this a cut-n-paste mistake?
Surprisingly (to me), no….
db=# select
"Abraham, Danny" writes:
> The function "to_date" does not fail illegal values.
> Is this a known bug?
No, it's a feature, because the point of to_date() is to parse strings
that would be rejected or misinterpreted by the regular date input
function. If you want tighter error checking and your i
20181501 is illegal. Working OK.
ctrlmdb=> select to_date('20181501','MMDD')
ctrlmdb-> \g
ERROR: date/time field value out of range: "20181501"
From: Ravi Krishna
Sent: Wednesday, October 23, 2019 5:28 PM
To: Abraham, Danny ; pgsql-gene...@postgresql.org
Subject: [EXTERNAL] Re: date function
On 10/23/19 7:22 AM, Abraham, Danny wrote:
Hi,
The function "to_date" does not fail illegal values.
Is this a known bug?
What is the recommended type checking?
ctrlmdb=> select to_date('2018100X','MMDD');
to_date
2018-10-01
(1 row)
At:
https://www.postgresql.org/docs
On 10/23/19 9:32 AM, Ravi Krishna wrote:
> postgres=# select to_date('2018150X','MMDD');
> to_date
> 2019-03-03
> postgres=# select to_date('20181501','MMDD');
> to_date
>
> 2019-03-03
is this a cut-n-paste mistake?
Nope.
Here's the screen print: http
> postgres=# select to_date('2018150X','MMDD');
> to_date
> 2019-03-03
> postgres=# select to_date('20181501','MMDD');
> to_date
>
> 2019-03-03
is this a cut-n-paste mistake?
> ctrlmdb=> select to_date('2018100X','MMDD');
> to_date
>2018-10-01
>(1 row)
I am able to reproduce this in 11.5 It seems PG can take a single digit for Day
too.
select to_date('2018109','MMDD') produces 2018-10-09.
On 10/23/19 9:22 AM, Abraham, Danny wrote:
Hi,
The function "to_date" does not fail illegal values.
Is this a known bug?
What is the recommended type checking?
ctrlmdb=> select to_date('2018100X','MMDD');
to_date
2018-10-01
(1 row)
psql (9.6.15)
Type "help" for help.
p
Hi,
The function "to_date" does not fail illegal values.
Is this a known bug?
What is the recommended type checking?
ctrlmdb=> select to_date('2018100X','MMDD');
to_date
2018-10-01
(1 row)
David G. Johnston wrote:
> Now if only the vast majority of users could have and keep this level of
> understanding
> in mind while writing complex queries so that they remember to always add
> protections
> to compensate for the unique design decision that SQL has taken here...
You can only say
51 matches
Mail list logo
