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. Unf
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
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
Tom Lane <[EMAIL PROTECTED]> writes:
> So far, the case hasn't been made for retail vacuum even ignoring the
> not-so-immutable-function risk.
Well the desire for it comes from a very well established need for dealing
with extremely large tales with relatively small hot spots. The basic problem
b
"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 presen
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Here's a small patch to add the full suite of btree operators for tids and
> > the
> > corresponding btree opclass.
>
> This has been proposed and rejected before, mainl
Here's a small patch to add the full suite of btree operators for tids and the
corresponding btree opclass. This came up a while back on -hackers and a few
people were interested in it at the time. I just had a need for it again so I
added it.
I'm not sure how to allocate OIDs. I just looked for
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 somethi
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 fun
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.
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 specifica
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 specificall
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 performan
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 th
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 f
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 inte
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 el
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 th
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 t
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&#
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 bei
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 viol
As described on -hackers this is my work so far adding ADD/DROP INHERITS. It
implements the controversial "ALTER TABLE ADD/DROP INHERITS "
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, it doesn't
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.\~
/r3/usr_local/src/pgsql/pgsql/src/backend/utils/a
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 edi
Bruce Momjian 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 wi
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 = 10
Bruce Momjian 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 haven't been followi
Bruce Momjian writes:
> I think we have concluded that the use of the ICU library is the way we
> are going to accomplish multi-locale support in the future.
You did? It really seemed like there was one crowd pushing ICU and hardly
anyone else interested in piling a huge library dependency on Po
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
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 sequentia
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > This patch allows subqueries without aliases. This is SQL-non-spec-compliant
> > syntax that Oracle supports and many users expect to work.
>
> AFAIR you're the first to pr
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
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > I inquired about this problem elsewhere, it's not a bug, it's an API change.
> > Until postgres "ports" to the new API it won't work with newer versions of
>
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 f
This patch adds an autoconf test to check for the new incompatible version of
flex.
--- programs.m4.~1.12.~ 2003-05-06 19:33:52.0 -0400
+++ programs.m4 2003-07-04 20:45:47.0 -0400
@@ -30,6 +30,10 @@
pgac_broken_flex=$pgac_candidate
continue
fi
36 matches
Mail list logo
