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
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
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
> 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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
>
> 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
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
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
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
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
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');
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
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
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:
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:
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.
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
44 matches
Mail list logo
