Craig Ringer writes:
>> - other products are happy to solve the DISTINCT restriction without
>> any hint as far as what the datatype really is
>
> ... and so is Pg. That's not the problem; Pg complains after resolving the
> SELECT DISTINCT, when it finds that it's trying to insert values of
On 7/06/2010 3:51 AM, Dimitri Fontaine wrote:
- other products are happy to solve the DISTINCT restriction without
any hint as far as what the datatype really is
... and so is Pg. That's not the problem; Pg complains after resolving
the SELECT DISTINCT, when it finds that it's trying to
Farid Zidan writes:
> I see no technical analysis in your response.
I made a clear reference to what others have been saying, and that you
have been refusing to read. I don't see any point in getting technical
again, as I'm sure you will refuse to understand what is happening to
you here.
But a
Dimitri
This is the last you will hear from me about this issue. I would have
stopped repsonding long time ago, but I kept getting responses that
required reply. Do not knock on the door if you don't want someone to
answer the door.
There is no point in spending more of my time explaining to
Farid Zidan writes:
> I am not asking you to re-write my sql so the bug will not show. I am
> presenting you with sql that fails and shows the bug. If every time
> someone reported a bug you ask them to re-write their sql so the bug
> is not hit, that would not eliminate the bug.
You're not readi
Title: Signature
Craig
I am not asking you to re-write my sql so the bug will not show. I am
presenting you with sql that fails and shows the bug. If every time
someone reported a bug you ask them to re-write their sql so the bug is
not hit, that would not eliminate the bug.
Also, you are usi
Title: Signature
Greg,
Obviously I do not agree. When 14 different databases by 14 different
DBMS vendors from the largest to the smallest in the market can do a
simple thing as a using a subquery that has distinct keyword and your
DBMS can't, I would say your DBMS is at fault and is not bette
I only use ODBC escape sequences when necessary. Obviously I want to
use standard sql syntax as much as possible. {fn user() } is handy
because it works in all the databases that I work with and there is no
substitute standard sql function for getting current userid that is
cross-dbms.
I also
On 05/06/10 06:15, Farid Zidan wrote:
> insert into test_insert
> (col1, col2)
> select *distinct*
> 'b',
> '2010-04-30 00:00:00'
>
>>Does not work. That's a bug.
Not really.
select distinct * from (VALUES
('b','2010-04-30 00:00:00'),
('b','2010-04-30 00:00:00'),
('b','20100430 00')
) AS x(
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Jun 04, 2010 at 06:15:09PM -0400, Farid Zidan wrote:
[...]
> Let me reiterate the example, maybe it was too terse and you did not
> read it carefully,
No. I think most readers here have understood your problem perfectly.
Don't underestimate t
On Fri, Jun 4, 2010 at 11:15 PM, Farid Zidan wrote:
> Now this not rocket science, it's simple insert statement where we do not
> want duplicates inserted. Works on 10 other DBMSs.
>
I find usually when one person is arguing something is complex and
someone else is arguing it's simple it's the pe
On Fri, 4 Jun 2010, Farid Zidan wrote:
Here is actual statements I am running and like I said they work for all 9+
DBMSs (I use ODBC and{fn user()} is the ODBC cross-dbms syntax for the
current user ID):
'2010-04-30 00:00:00',
'2010-04-30 00:00:00',
{fn user() }
If you're into using standa
Title: Signature
Hello Kevin,
I can't help but wonder why you resist using the standard syntax.
I am using the standard syntax. Single quote in sql denotes a string.
so '2010-04-30 00:00:00' is string literal. That's universal. Now you
want me to use PG-specific timestamps and that's l
Title: Signature
Hello Greg,
I suspect what they're doing is doing a DISTINCT of the text values
and then converting the results. That's not the same as what you're
suggesting it do (insert distinct timestamp values) since different
text values can represent the same timestamp. For example
>Farid Zidan wrote:
> but when it gets to use the resultset of the subquery in the
> insert it "forgets" how to convert '2010-04-30 00:00:00' to
> timestamp value
Not really. In versions prior to 8.3 it did automagically convert
like that. PostgreSQL has some pretty fancy features involving
On Fri, Jun 4, 2010 at 7:18 PM, Farid Zidan wrote:
> If a simple SQL statement works on 9+ different databases
For what it's worth are you sure it works as you expect in these other
databases?
I suspect what they're doing is doing a DISTINCT of the text values
and then converting the results. Th
16 matches
Mail list logo
