Farid Zidan fa...@zidsoft.com 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
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
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
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
Farid Zidan fa...@zidsoft.com 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.
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
On Fri, Jun 4, 2010 at 7:18 PM, Farid Zidan fa...@zidsoft.com 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
Farid Zidan fa...@zidsoft.com 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
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
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
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
On Fri, Jun 4, 2010 at 11:15 PM, Farid Zidan fa...@zidsoft.com 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
-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,br
No. I think most readers here have understood your problem perfectly.
Don't underestimate
13 matches
Mail list logo
