Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
This patch adds an autoconf test to check for the new incompatible version of
flex.
It seems unlikely that we should cause configure to reject all future
versions of flex... .31 may be broken but I think we should
T E Schmitz [EMAIL PROTECTED] writes:
There's a German saying Go and find a parking-meter, i.e. suggesting to pop a
coin in the parking-meter and talk to it as nobody else wants to listen. ;-)
Yes well I anticipated such a response. So I tried my hand at it myself.
Well I finally found a
Greg Stark [EMAIL PROTECTED] writes:
Dennis Bjorklund [EMAIL PROTECTED] writes:
On 22 Sep 2004, Greg Stark wrote:
Actually this looks like it's arguably a bug to me. Why does the hash
join execute the sequential scan at all? Shouldn't it also like the
merge join recognize
Tom Lane [EMAIL PROTECTED] writes:
Yeah, I was just looking at doing that.
Well I imagine it takes you as long to read my patch as it would for you to
write it. But anyways it's still useful to me as exercises.
It would also be interesting to prefetch one row from the outer table and fall
Bruce Momjian pgman@candle.pha.pa.us writes:
I don't think so. I think trait and property suggests an aspect of the
object, so saying trait/property size is saying I am talking about an
aspect of the object, while for a heap, its size is really its size, it
isn't an aspect of its size.
I
Tom Lane [EMAIL PROTECTED] writes:
Applied with revisions: I made it use the VacRUsage code so that we
could see both CPU and elapsed time, and moved the report points around
a bit. The output with trace_sort enabled looks like this:
NOTICE: begin tuple sort: nkeys = 1, workMem = 1024,
Bruce Momjian pgman@candle.pha.pa.us writes:
Devrim GUNDUZ wrote:
Hi,
On Wed, 2006-01-25 at 11:28 -0500, Tom Lane wrote:
Devrim GUNDUZ [EMAIL PROTECTED] writes:
Attached is a patch which adds --quiet and --q option to initdb.
Why is this a good idea?
I was playing with
David Fetter [EMAIL PROTECTED] writes:
Not everybody's editor/mailer/whatever does this right, and it makes
things fragile. Another way to do this is to change the delimter to a
printable character like '|', but that raises hackles, too.
Frankly if you're passing you data through an
I'm sure nobody was really confused by this little copy/paste oops in the
comments but just for the hell of it.
cd /r3/usr_local/src/pgsql/pgsql/src/backend/utils/adt/
diff -c /r3/usr_local/src/pgsql/pgsql/src/backend/utils/adt/name.c.\~1.58.\~
As described on -hackers this is my work so far adding ADD/DROP INHERITS. It
implements the controversial ALTER TABLE table ADD/DROP INHERITS parent
syntax that requires making INHERITS a reserved keyword. I haven't seen a
clear consensus yet on what the best syntax to use here would be.
Also,
Tom Lane [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
We should try very hard to avoid adding new reserved words, IMNSHO.
*Especially* ones not sanctioned by the SQL spec. Reserving a word that
is not listed as reserved in the standard is really a spec violation,
This is where I am with the ADD/DROP INHERITS patch now.
1) The syntax is:
ALTER TABLE child INHERIT parent
ALTER TABLE child NO INHERIT parent
no new reserved words, no conflicts, no complicated grammar productions in
gram.y to confuse people in the future.
2) Dependencies are
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
I also haven't checked the constraint name. To do so it would make sense
to
use a small hash table.
No, it'd make sense to use strcmp(). It's unlikely that there will be
enough constraints attached to any
Tom Lane [EMAIL PROTECTED] writes:
I don't believe those attributes mean anything for check constraints
ATM, but you may as well compare them anyway. If we ever do implement
them then it'd be reasonable to expect parent and child to have
identical settings.
I'm not sure. Does it have to
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
So should I set up a nested scan, essentially implementing a nested loop? or
should I gather together all the children in a list?
I'd use the predigested form of the constraints attached to the Relation
tupledescs
I couldn't figure out how to make use of the predigested constraints in the
relcache, so I continued on the tack I was on. I just stuf the entire
HeapTuple in a list and decompiled the constraint source only if I find a
constraint with a matching name.
Points I'm uncertain about:
. I throw an
I cleaned up the code and added some more documentation.
I think I've addressed all the concerns raised so far. Please tell me if I've
missed anything.
There were a few tangentially related issues that have come up that I think
are TODOs. I'm likely to tackle one or two of these next so I'm
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2006-06-12 at 17:39 -0400, Greg Stark wrote:
Points I'm uncertain about:
. I throw an elog() error if there's a null conbin for a CHECK constraint.
Is
it possible for a valid CHECK constraint structure to have a null conbin
Tom Lane [EMAIL PROTECTED] writes:
If you're happy with the code looking directly at pg_constraint then
I see no reason to change it. I just mentioned the relcache because
I thought you were concerned about the performance of a pg_constraint
search.
I'm not concerned with the performance
I just managed to crash the server so I guess this isn't finished, but I'm
posting it in the post early post often spirit. Aside from error checks it
also needs docs and tests of course.
This patch implements an option to copy check constraints when using LIKE.
Because the standard specifically
Fixed the bug, added docs and tests.
like.patch3
Description: Binary data
The previous message explaining the patch:
Greg Stark [EMAIL PROTECTED] writes:
This patch implements an option to copy check constraints when using LIKE.
Because the standard specifically excludes constraints
Greg Stark [EMAIL PROTECTED] writes:
This patch implements an option to copy check constraints when using LIKE.
Ah, found a problem. I need to do a change_varattnos_of_a_node() call here.
Should this function maybe be promoted to some other file like ruleutils.c?
--
greg
Fixed previous patch by calling change_varattnos_of_a_node() to fix up
constraint expressions in case attribute positions don't line up.
change_varattnos_of_a_node is in tablecmds.c for inherited tables so this
means making it extern. I have a feeling it probably ought to move to some
file of
Alvaro Herrera [EMAIL PROTECTED] writes:
Hum, how are you handling the case where I specify
CREATE TABLE LIKE x INCLUDING CONSTRAINTS EXCLUDING CONSTRAINTS ?
I have the last one taking priority. I could make it an error but don't see
much point in doing so. It seems to be making something
Marc G. Fournier [EMAIL PROTECTED] writes:
'k, isn't the Reply-To header part of an RFC somewhere? Or is it really an
optional thing for an MUA to follow?
The relevant RFC would be 2822.
If mailers have started ignoring reply-to it would be *because* of lists that
set it. In the presence of
Jim Nasby [EMAIL PROTECTED] writes:
Even if we stopped right there it would still be a huge win in many (most?)
cases. How often do the indexes on a table comprise even 50% of the table's
size?
I would say they're usually roughly comparable actually. It depends on how
wide your table is
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Updated patch. Fixed a few minor things, added documentation and regression
tests. Unfortunately I can't test the regression tests because I get a
segmentation fault earlier in the same file due to a GIN index build
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Updated patch. Fixed a few minor things, added documentation and
regression
tests. Unfortunately I can't test the regression tests because I get a
segmentation fault
28 matches
Mail list logo
