Hi,
On 5/3/07, Tom Lane [EMAIL PROTECTED] wrote:
NikhilS [EMAIL PROTECTED] writes:
Hi Neil,
* the patch is broken for expressional indexes, and silently omits
copying the predicate that may be associated with an index.
Since this patch is only supposed to copy unique/primary indexes, I
On 3/17/07, Tom Lane [EMAIL PROTECTED] wrote:
Jaime Casanova [EMAIL PROTECTED] writes:
On 3/5/07, Tom Lane [EMAIL PROTECTED] wrote:
In the second place, it's a serious violation of what little modularity
and layering we have for fd.c to be calling into commands/tablespace.c.
This is not
NikhilS [EMAIL PROTECTED] writes:
But this patch is not for the INCLUDING INDEXES case.
Pardon me for being misled by the thread title :-(
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive
On Wed, May 02, 2007 at 05:25:39PM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Given this, perhaps the proper approach should instead be to just check
the return value, and go from there? Should be a simple enough patch,
something like the attached.
Tom, can you
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
The attached docs patch makes clearer how arguments and return values in
pl/perl are escaped. This is to clarify the situation that Theo
Schlossnagle recently reported on -bugs.
If there's no objection I will apply this.
cheers
andrew
? plperldoc.patch
Index: plperl.sgml
Andrew Dunstan wrote:
The attached docs patch makes clearer how arguments and return values in
pl/perl are escaped. This is to clarify the situation that Theo
Schlossnagle recently reported on -bugs.
I find the mix of arguments and results a bit confusing. Maybe you
could put them in
Alvaro Herrera wrote:
Andrew Dunstan wrote:
The attached docs patch makes clearer how arguments and return values in
pl/perl are escaped. This is to clarify the situation that Theo
Schlossnagle recently reported on -bugs.
I find the mix of arguments and results a bit confusing.
Gregory Stark [EMAIL PROTECTED] writes:
Updated patch against cvs update in case it makes applying easier.
Applied with revisions --- notably, I avoided adding any overhead to
HEAPCOMPARE() by the expedient of reversing the logical sort order
before heapify'ing. We couldn't have done that
Andrew Dunstan [EMAIL PROTECTED] writes:
Is this better?
I suggest bytea - typebytea/, otherwise seems fine.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Mon, 2007-30-04 at 00:04 -0400, Tom Lane wrote:
I'm still not very comfortable with that. You're proposing to add a
pretty obvious failure mechanism --- any numeric-returning function
that failed to normalize its output would now create a subtle,
hard-to-find bug.
What about teaching
Neil Conway [EMAIL PROTECTED] writes:
On Mon, 2007-30-04 at 00:04 -0400, Tom Lane wrote:
I'm still not very comfortable with that. You're proposing to add a
pretty obvious failure mechanism --- any numeric-returning function
that failed to normalize its output would now create a subtle,
12 matches
Mail list logo