10x,
Found my answer thanks to Ragnar.
SELECT DISTINCT ON (a0,a1) a0,a1,ctid FROM t1
To tell the truth, i did not know there was an ON option in SQL.
This thing is very handy.
On Saturday 29 July 2006 03:37, Tzahi Fadida wrote:
Hi,
I have a query i am having trouble to formulate:
I used to
Is anyone working on this?
Tom Lane wrote:
korry [EMAIL PROTECTED] writes:
The problem is that, each time you go through
pgwin32_waitforsinglesocket(), you tie the *same* kernel object
(waitevent is static) to each socket.
The fix is pretty simple - just call WSAEventSelect( s,
Luke Lonergan wrote:
Mark,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, July 28, 2006 9:26 PM
But irrefutable? Irrefutable is not true. :-)
How about unrefuted. The evidence has not been refuted, and not
directly discussed or
heh. I was just doing it the way Tom suggested - see attached. With a
little more trouble we could also keep track if the listened for events
and sometimes save ourselves a second call to WSAEventSelect, but I'm
not sure it's worth it.
cheers
andrew
[EMAIL PROTECTED] wrote:
Is anyone
I am trying to use pgindent but it adds ^M in my files.
However, it doesn't add it to postgresql src files (i tried).
I guess it is maybe something with encoding?
What can i do?
10x.
--
Regards,
Tzahi.
--
Tzahi Fadida
Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
Tzahi Fadida wrote:
I am trying to use pgindent but it adds ^M in my files.
However, it doesn't add it to postgresql src files (i tried).
I guess it is maybe something with encoding?
What can i do?
10x.
On what platform and on what files?
cheers
andrew
---(end of
Andrew Dunstan wrote:
Tzahi Fadida wrote:
I am trying to use pgindent but it adds ^M in my files.
However, it doesn't add it to postgresql src files (i tried).
I guess it is maybe something with encoding?
What can i do?
10x.
On what platform and on what files?
Sounds like windows :)
These are .c and .h files on linux.
Also i am using the patched indent and compiled the entab, etc...
From 8.2
On Saturday 29 July 2006 17:57, Andrew Dunstan wrote:
Tzahi Fadida wrote:
I am trying to use pgindent but it adds ^M in my files.
However, it doesn't add it to postgresql src files
On Sat, Jul 29, 2006 at 03:37:15AM +0300, Tzahi Fadida wrote:
Hi,
I have a query i am having trouble to formulate:
I used to do:
SELECT DISTINCT a0,a1 FROM public.t1
However, now i need to add the CTID attribute, but CTID is unique
thus, distinct is useless. In addition, i can't seem to be
Bruce,
On 7/29/06 6:31 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
Right. People need a patch to test on their workloads, and analysis can
be done after feature freeze.
Fair enough.
- Luke
---(end of broadcast)---
TIP 5: don't forget to
Are we done with the sort interrupt issue mentioned in the subject line,
and the issue outlined below?
---
Tom Lane wrote:
Charles Duffy [EMAIL PROTECTED] writes:
... For the 'long' data, the compare moves on rightward
Patch applied. Thanks.
---
Hiroshi Saito wrote:
Ooops,
I am uncertain at the reason for not knowing __BORLANDC__...
It will be sure if __BORLANDC__ has the definition.
Thanks.
Regards,
Hiroshi Saito
From: Tom
Clarification, the attached version with the BORLAND adjustment is the
one that was applied.
---
Bruce Momjian wrote:
Patch applied. Thanks.
---
Tom, thank you for the reviewing/correcting/applying my patches...
On Fri, 28 Jul 2006, Tom Lane wrote:
I wrote:
There is room to argue that the numeric-arithmetic version would be
worth having on the grounds of greater precision or range, but it's a
big chunk of code and the public demand
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Does it not like static functions?
I seem to recall Robert mentioning that they'd only recently fixed
DTrace to cope with probes in static functions. Maybe you need to
get an update?
That rings a bell. Can we get a more precise
On Sat, Jul 29, 2006 at 01:37:44PM +0300, Tzahi Fadida wrote:
10x,
Found my answer thanks to Ragnar.
SELECT DISTINCT ON (a0,a1) a0,a1,ctid FROM t1
To tell the truth, i did not know there was an ON option in SQL.
This thing is very handy.
There isn't, it's a postgresql extension, albeit a
Sergey E. Koposov wrote:
I think since we are supporting the numeric type as a special
high-precision type, Postgres must have the high-precision
versions of all computational functions. Just my opinion.
Another way to look at it is whether you want to have accurate
computations (numeric) or
On Sat, 29 Jul 2006, Peter Eisentraut wrote:
Sergey E. Koposov wrote:
I think since we are supporting the numeric type as a special
high-precision type, Postgres must have the high-precision
versions of all computational functions. Just my opinion.
Another way to look at it is whether you
heh. I was just doing it the way Tom suggested - see attached. With a
little more trouble we could also keep track if the listened for events
and sometimes save ourselves a second call to WSAEventSelect, but I'm
not sure it's worth it.
It all depends on the overhead of
Ühel kenal päeval, L, 2006-07-29 kell 18:25, kirjutas Martijn van
Oosterhout:
On Sat, Jul 29, 2006 at 03:37:15AM +0300, Tzahi Fadida wrote:
Hi,
I have a query i am having trouble to formulate:
I used to do:
SELECT DISTINCT a0,a1 FROM public.t1
However, now i need to add the CTID
[EMAIL PROTECTED] wrote:
heh. I was just doing it the way Tom suggested - see attached. With a
little more trouble we could also keep track if the listened for events
and sometimes save ourselves a second call to WSAEventSelect, but I'm
not sure it's worth it.
It all depends on the
Bruce Momjian [EMAIL PROTECTED] writes:
I modified pg_regress.c to use just the return code to determine if the
diff worked, but I added in a WIN32-specific test for the file size. I
think that is the cleanest solution. Attached.
It really needs a comment, along the lines of
/*
Bruce Momjian [EMAIL PROTECTED] writes:
Are we done with the sort interrupt issue mentioned in the subject line,
and the issue outlined below?
I'm inclined not to apply the proposed patch (adding
CHECK_FOR_INTERRUPTS) because of the risk of memory leakage inside
qsort. OTOH you could argue
Peter Eisentraut [EMAIL PROTECTED] writes:
... From a mathematician's point of view, however, some of these
functions normally produce irrational numbers anyway, so it seems
unlikely that numeric will be useful. But looking at the definition
of, say, regr_avgx(Y, X), if all the input
Tom Lane wrote:
If I'm reading the spec correctly, VALUES is exactly parallel to SELECT
in the grammar, which means that to use it in FROM you would need
parentheses and an alias:
SELECT ... FROM (SELECT ...) AS foo
SELECT ... FROM (VALUES ...) AS foo
One of the things I'm
Joe Conway [EMAIL PROTECTED] writes:
One of the things I'm struggling with is lack of column aliases. Would
it be reasonable to require something like this?
SELECT ... FROM (VALUES ...) AS foo(col1, col2, ...)
Requiring column aliases is counter to spec ...
The other issue is how to
Greg Sabino Mullane [EMAIL PROTECTED] writes:
small patch to provide a new variable server_version_num, which is
almost the same as server_version but uses the handy PG_VERSION_NUM
which allows apps to do things like if ($version = 80200) without
having to parse apart the value of
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
One of the things I'm struggling with is lack of column aliases. Would
it be reasonable to require something like this?
Requiring column aliases is counter to spec ...
SELECT ... FROM (VALUES ...) AS foo(col1 type1, col2 type2,
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Are we done with the sort interrupt issue mentioned in the subject line,
and the issue outlined below?
I'm inclined not to apply the proposed patch (adding
CHECK_FOR_INTERRUPTS) because of the risk of memory leakage inside
qsort.
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
As for the types, I believe that the spec pretty much dictates that we
apply the same type resolution algorithm as for a UNION.
Where do I find that algorithm -- somewhere in nodeAppend.c?
select_common_type(), in the parser.
Alvaro Herrera wrote:
Here is a patch pursuant to there ideas. The main change is that in
GetSnapshotData, a backend is skipped entirely if inVacuum is found to
be true.
Patch applied.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company -
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
FWIW: lionfish had a weird make check error 3 weeks ago which I
(unsuccessfully) tried to reproduce multiple times after that:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfishdt=2006-05-12%2005:30:14
Weird.
32 matches
Mail list logo
