t
> > have time for it right now.
>
> Well, if nothing else, the potential is there for a future release.
That's kinda where I am on this one. In the grand PostgreSQL
tradition, we can have something that works before we have something
that works fast :)
> I'm probabl
On Fri, Feb 25, 2011 at 10:12:02PM -0500, Tom Lane wrote:
> David Fetter writes:
> > What's the effect, if any, on CTEs that depend on each other
> > explicitly?
>
> An error. That would require mutual recursion, which we don't
> support for the SELECT case l
the same complaint when I looked at this patch
> > a year ago, but didn't come up with nearly as good an idea as to
> > what to do about it.
>
> I like "statement" better than "command," too, but love the acronym
> DMC. As in, "you want t
her than relying on the acronym.
> In the code, we could change hasDmlWith to hasModifyingWith, for
> example. The error messages could read like
> data-modifying statement in WITH is not allowed in a view
>
> Comments?
+1
If we ever decide add in what I'd originally envi
eeded.
> Then, in ExecutorEnd, cycle any unfinished ModifyTable nodes to
> completion before shutting down the plan. (In the event of an error,
> we'd never get to ExecutorEnd, but it doesn't matter since whatever
> updates we did apply are nullified anyhow.)
What's t
and it.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://ww
the compiles-in-isolation test for
> headers?
Both sound reasonable, given the number of times they come up and the
ease of checking them mechanically.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fe
On Thu, Feb 10, 2011 at 09:16:09PM +0200, Peter Eisentraut wrote:
> On tor, 2011-02-10 at 10:40 -0800, David Fetter wrote:
> > I think all such checks belong in .git/hooks/pre-commit, and need
> > to be as cross-platform as needed for committers. Would a
> > *n*x-based v
On Thu, Feb 10, 2011 at 12:58:16PM +0200, Peter Eisentraut wrote:
> On ons, 2011-02-09 at 08:00 -0800, David Fetter wrote:
> > On Wed, Feb 09, 2011 at 01:17:06PM +, Bruce Momjian wrote:
> > > Remove more SGML tabs.
> >
> > Perhaps we should see about putting some
the fact that our build system already requires Perl, there
should be, but I'm not quite sure how this would be accomplished.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
xample of how our current shared memory
> model is a piece of garbage.
What other model(s) might work better?
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.
On Tue, Feb 08, 2011 at 02:04:04PM -0500, Robert Haas wrote:
> On Tue, Feb 8, 2011 at 1:02 PM, David Fetter wrote:
> > Given how things worked, i.e. that people were not clear that 9.1
> > development had actually started, etc., I am again proposing that we
> > have one more
to commit this?
I think we're faced with the hard reality that we can't get a perfect
implementation of this in one go, as that would involve pulling the
"correctness" bits away from the OS-supplied libraries, etc., and into
PostgreSQL. I'm all for doing this eventually,
- implementation
> * typmod support (optional)
>
> This is nearing completion. GiST is by far the most amount of effort
> remaining that I'm aware of. Comments about the API, naming,
> representation, interface, funcationality, grammar, etc. are welcome.
>
> Regards,
&g
d use of
money would be an extension to the pgbuildfarm code that detects and
acts on bit rot. I don't have time to build it right now, but I'd be
happy to iron out the spec and help someone else, that person being
paid to develop it.
Cheers,
David.
--
David Fetter http://fetter.org/
l-volunteer effort. You
may get people to do things they might not otherwise have done, but
you'll also make people wonder whether they should be volunteering at
all.
Offhand, I'd say this is a really bad idea.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 37
gt;realistically try to support every possible locale in the tests.
>
> Maybe someone would like to set up a buildfarm member that tests a
> whole slew of locales. We've had the capability for a couple of
> years now.
Is it just a matter of setting a flock of environment
her making adminpack part of
PostgreSQL's core distribution (probably a good idea) or moving it out
of pg_catalog so we don't have an exception to the rule.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter
nd: 77
>
> ie repeat the label of the filtering condition exactly. This is looking
> pretty long, but from the viewpoint of vertical or horizontal space
> occupied by the printout, I doubt it matters.
+1 for this. It says what happened. :)
Cheers,
David.
--
David Fetter htt
w. I could try to check that and fix it, but not sure if I'll have the
> time, and it's been that way before. Also, the CF is already closed in
> theory...
If you're fixing things in PL/PythonU, such a change would certainly
be in scope as an update to your patch, i.e. don
On Tue, Jan 18, 2011 at 09:14:41PM +1300, Mark Kirkwood wrote:
> On 18/01/11 18:04, Tom Lane wrote:
> >David Fetter writes:
> >>Who's the copyright holder(s)? If it's all individual
> >>contributors, Red Hat policy is not in play.
> >Sorry
e can't because
> of license issues. pg_filedump is GPL, per Red Hat company policy,
> and that's not going to change.)
Who's the copyright holder(s)? If it's all individual contributors,
Red Hat policy is not in play.
Cheers,
David.
--
David Fetter http://fetter.org/
P
e top of the generic
> function in a straightforward way.
>
> NULL bounds, however, have been causing me a little frustration.
> [Explanation and illustrations].
In that case, let's leave them out for this cut.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 41
question was settled by a notice, that would also be the
> proper answer for the former.
>
> Perhaps the next thing is that MERGE should return INSERT or UPDATE
> depending on the outcome?
Given that it can do both in a single statement, I'm guessing that
this is intended
't, serializable transactions might not work.
When you tell the system an untruth about the state of the world, such
as alleging immutability when it's not actually there, it will get its
revenge in ways more drastic than this.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +
le
> > aren't likely to misunderstand it.
>
> The term "procedural" in this context originated with Oracle's
> PL/SQL, which is a procedural language extension to the
> non-procedural SQL language.
We can repurpose 'P' to mean, Programming or PostgreSQL
On Thu, Jan 13, 2011 at 03:29:13PM -0800, Jeff Davis wrote:
> On Thu, 2011-01-13 at 11:14 -0800, David Fetter wrote:
> > I get that we can't prevent all pilot error, but I was hoping we
> > could bullet-proof this a little more, especially in light of a
> > certain ext
On Thu, Jan 13, 2011 at 02:21:44PM -0500, Tom Lane wrote:
> David Fetter writes:
> > I get that we can't prevent all pilot error, but I was hoping we
> > could bullet-proof this a little more, especially in light of a
> > certain extremely popular server OS's OO
awns. It never has to read/write to it,
> > but postmaster closing will signal the client's fd. The client
> > just has to pop the fd into whatever nrmal poll/select event
> > handlign it uses to notice when the "parent's pipe" is closed.
>
> I just sta
, I get that that behavior is crazy, and stupid, and that people
should shut it off, but it *is* our problem if we let the postmaster
start (or continue) when it's set that way.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: d
> test db model
Please put a self-contained example on the snippets page, and please
also to check that it actually runs before doing so. You'd mangled
some aliases in the query you sent, which leads me to believe you
hadn't actually tried running it.
Cheers,
David.
--
David Fetter ht
On Thu, Jan 13, 2011 at 10:41:28AM -0500, Tom Lane wrote:
> David Fetter writes:
> > I've noticed over the years that we give people dire warnings never to
> > send a KILL signal to the postmaster, but I'm unsure as to what are
> > potential consequences of this,
ons
of the mechanism(s) whereby the damage occurs?
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote
e
> creatable order of objects:
>
> WITH
> NewObjectOids AS (
> SELECT * FROM pg_depend WHERE deptype <> 'p'
> EXCEPT
> SELECT * FROM pg_depend_before
To what does pg_depend_before refer?
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 41
o the new behavior.
>
> [ Id actually vote for _not_ having a compatibility option at all,
> we change more major things than this IMHO every major release. (And
> even then some major things in minor releases, for example the
> removal of Safe.pm) ]
+1 for changing the behavior
On Wed, Jan 12, 2011 at 10:24:31AM -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 12.01.2011 17:15, David Fetter wrote:
> >> On Wed, Jan 12, 2011 at 10:26:05AM +0100, marcin mank wrote:
> >>> Considering that parallell base backups would be io-bound (or
On Wed, Jan 12, 2011 at 05:17:38PM +0200, Heikki Linnakangas wrote:
> On 12.01.2011 17:15, David Fetter wrote:
> >On Wed, Jan 12, 2011 at 10:26:05AM +0100, marcin mank wrote:
> >>Considering that parallell base backups would be io-bound (or
> >>network-bound), there is
t's not actually true. Backups at the moment are CPU-bound, and
running them in parallel is one way to make them closer to I/O-bound,
which is what they *should* be.
There are other proposals out there, and some work being done, to make
backups less dependent on CPU, among them:
- Maki
it to work when the chips were down.
>
> I hope this assessment proves to be incorrect, because like Magnus and
> Heikki, I think this will be a major usability improvement. It takes us from
> "there's a way to do that" to "it just works".
(It just works)++ :)
hem around later. Suggestions? And what should the overall
> alignment of the range type be?
For the first cut, the simplest possible.
> * If it's a fixed-length type, we can save the varlena header byte on
> the overall range; but we lose the ability to save space when one
On Mon, Jan 10, 2011 at 10:03:18AM -0600, Kevin Grittner wrote:
> Due to popular request (Hey, David's popular, right?),
Well, I'm a person, and "popular" originally refers to something like
that ;)
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 23
On Mon, Jan 10, 2011 at 08:59:45AM -0600, Kevin Grittner wrote:
> David Fetter wrote:
> > Could people fix it after the patch? ISTM that a great way to
> > test it is to make very sure it's available ASAP to a wide range
> > of people via the next alpha (or beta, i
ore cutting a patch.
Could people fix it after the patch? ISTM that a great way to test it
is to make very sure it's available ASAP to a wide range of people via
the next alpha (or beta, if that's where we're going next).
Cheers,
David.
--
David Fetter http://fetter
rk compatibly ... but now there is, so I see no
> reason to remain bug-compatible with this behavior.
>
> Barring objections, I'm going to fix it.
+1 for fixing it.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfe
provide legacy behavior
> for SERIALIZABLE transactions -- if set, SERIALIZABLE would fall
> back to working the same as REPEATABLE READ.
>
> In an off-list exchange with me, David Fetter expressed opposition
> to this, as a foot-gun. I'm not sure where anyone else stands on
> th
tters with a big "you are here" X marking where
> they have inadvertently wandered onto.
Actually, that'd make a great flow chart on a T-shirt :)
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter
ntial use for it would be for some kind of am
that *couldn't* index nulls out of the gate. Might their be such AMs
on the horizon?
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
On Fri, Jan 07, 2011 at 10:58:41AM -0500, Robert Haas wrote:
> On Fri, Jan 7, 2011 at 10:52 AM, David Fetter wrote:
> > I'm not sure I understand this. Does it mean I'd have to say
> >
> > LOCK TABLE my_view;
>
> No.
+1 for #4, then :)
Cheers,
David
TABLE my_view;
? If so, I don't think that's a great idea. We used to have to do
TABLE operations on SEQUENCEs because they just happened to be
implemented as special tables, which wired implementation details into
the API. This is Generally Not A Good Thing™, and we removed th
sure I get the connection between this type of range and the
"range types" Jeff is working on. Jeff's work involves a way to
create types which represent ranges over types which have some kind of
ordering, although not necessarily a successor operation.
Had you planned to cas
On Wed, Jan 05, 2011 at 10:19:23AM +0100, Dimitri Fontaine wrote:
> David Fetter writes:
> > One could imagine that an extension was updated more quickly than
> > PostgreSQL major versions come out, or at least not at the exact same
> > time.
>
> Sure, but I don'
; > Going logged -> unlogged has a significant placed, I think.
>
> Interesting. So you'd change a logged table into an unlogged table
> to cut down on I/O, and take the risk of losing the data if the
> server went down?
BLACKHOLE is a "storage engine" that's equiva
On Tue, Jan 04, 2011 at 09:27:10PM -0500, Greg Smith wrote:
> David Fetter wrote:
> >How about implementing an UPSERT command as "take the lock, do the
> >merge?" That way, we'd have both the simplicity for the simpler cases
> >and a way to relax consistency gu
On Tue, Jan 04, 2011 at 08:31:19PM +0100, Dimitri Fontaine wrote:
> David Fetter writes:
> > Do you plan to have
> >
> > ALTER EXTENSION ... UPGRADE TO VERSION ...
> >
> > , or the more general,
> >
> > ALTER EXTENSION ... ALTER VERSION TO ... ?
>
ven to newbies, which none of the other view names would ...
Wait. We can't do that. We'd be breaking a decades-old tradition of
terrible names! ;)
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XM
On Tue, Jan 04, 2011 at 07:02:54PM +0200, Marko Tiikkaja wrote:
> On 2011-01-04 6:27 PM, David Fetter wrote:
> >On Tue, Jan 04, 2011 at 04:44:32AM -0500, Greg Smith wrote:
> >>Heikki Linnakangas wrote:
> >>>You can of course LOCK TABLE as a work-around, if that'
that this might not be a 9.1 feature, but it's sure to be one
people who need to deploy software want. A lot.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit
loops).
I believe it is possible. I'll try to do it this evening.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tr
k, do the
merge?" That way, we'd have both the simplicity for the simpler cases
and a way to relax consistency guarantees for those who would like to
do so.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: d
annot be used on views" seems more awkward to me.
> Or do we think that's OK?
That particular one looks good insofar as it describes reality. With
predicate locks, etc., it may become untrue later, though :)
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
"subqueries"
> already mentioned in the docs are common table expressions.
+1
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/
ces to the
previous threads you have in mind rather than simply mention that they
exist.
Saying, in effect, "search the archives with our not-super-great
search technology using keywords you didn't think of," comes off as
pretty dismissive if not downright hostile.
Cheers,
David
On Wed, Dec 29, 2010 at 11:47:53AM +0100, Magnus Hagander wrote:
> Would people be interested in putting pg_streamrecv
> (http://github.com/mhagander/pg_streamrecv) in bin/ or contrib/ for
> 9.1? I think it would make sense to do so.
+1 for bin/
Cheers,
David.
--
David Fetter http://f
instead refactor the docs to point
to CTEs in the appropriate places, and it's my hope that those places
will increase over time.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
ger query". I'm concerned that this might
> not be strictly correct, because the term "WITH query" may not be
> exactly equivalent to the term "CTE" - WITH queries are comprised of
> one or more CTEs, plus a main query. Or are they?
They are. :)
Cheers,
David
On Mon, Dec 27, 2010 at 09:51:01PM -0500, Robert Haas wrote:
> On Mon, Dec 27, 2010 at 9:28 PM, David Fetter wrote:
> > On Tue, Dec 28, 2010 at 12:19:47AM +, Peter Geoghegan wrote:
> >> It's worth noting that officially (i.e. in the docs), we don't even
> >
ed.
> Is there interest in correcting this, by putting "CTEs" or "Common
> table expressions" in parenthesis after "WITH queries" in the docs
> at certain select places? I could write a documentation patch.
+1 :)
Cheers,
David.
--
David Fetter http://fette
o be quite a challenge.
>
> *Writing* CTEs is more accurate.
OK :)
On the bright side, we have a decades-long tradition of horrible names
on this project, one early example of which is a name that abbreviates
the phrase, 'POST-"interactive GRaphics REtrieval System.&quo
beyond the point where we rely on
> individuals doing this sort of stuff.
This sounds like an excellent early candidate for the bitrot farm.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...
y " (e.g. "views do not support
> SET NOT NULL"). But that breaks our guideline about assembling
> translatable strings from small pieces. Maybe it'd be OK if the piece
> is just a fragment of SQL syntax, though - not sure.
>
> Or we can just stick with th
d most of the bugtrackers I've had to search have way *less*
> >ease-of-use for searching than a good mailing list archive (I tend
> >to keep going back to gmane's search)
>
> It's deja vu all over again. See mailing list archives for details.
LOL!
Cheers,
David.
he CTE, not just DML writes. You can
imagine cases for DCL (GRANT/REVOKE based on a catalog query) or DDL
(partition management), and I did.
We could call them, "Expanded CTEs," but that only freezes the prior
norm making them read-only, so I think "Writeable CTEs" captures it
p
s we add more cache.
>
> What I am arguing in favour of is an option to allow people to protect
> their data, whatever the size of their cache. I'm not forcing you or
> anyone to use it, but I think its an important option to be offering to
> our users.
For what version of Postgr
lot of things--streams of data, for
> > example--is infinity. I suppose that's a good default for some cases.
>
> Since we don't have streaming queries,
We don't, but other systems do.
> this would seem rather pointless ... Surely the FDW must be able to
>
resumably no LOCK is
> passed through to the FDW?
Depends...
> 22. Can we build an local index on a foreign table?
Dunno. In principle, it might be possible, but there are pretty
thorny caching issues that make this an edge case. I can imagine some
gigantic read-only store where this
t; That answers another question also.
There might be some cases where we can say an expression on a set of
columns is unique, but not in the general case. In the general case,
we can't even guarantee 1NF.
> Still many unanswered.
Will try these later today :)
Cheers,
David.
--
Davi
anyway.
>
> To pick up an earlier thread again, has any serious thought been given
> to adapting the SQL2001/DB2 syntax instead of our own?
Yes, and it's a good deal more limited and less intuitive than ours.
This is one place where we got it right and the standard just got
pushed int
character sets. I've
> heard this before but never found what's missing. [citation needed]?
Windows-1252, ISO-2022-JP-2 and EUC-TW are such encodings.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: davi
; instead of leaving it as 1). In this case the 333 causes perl
> > store it internally as utf8.
>
> Well with SQL_ASCII anything goes, no?
Anything except a byte that's all 0s :(
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yaho
On Thu, Dec 16, 2010 at 07:40:31AM -0500, Greg Smith wrote:
> David Fetter wrote:
> >That we're in the position of having prevN_wd for N = 1..5 as the
> >current code exists is a sign that we need to refactor the whole
> >thing, as you've suggested before.
&
even if we support some kinds of built-in update feature,
> I still think RULE and TRIGGER are useful, for example, logging
> purpose.
Please start with TRIGGER, and we can then discuss the whether and
possibly the how of RULEs later.
Cheers,
David.
--
David Fetter http://fetter
On Mon, Dec 13, 2010 at 10:48:54PM -0500, Robert Haas wrote:
> On Tue, Nov 30, 2010 at 9:15 AM, David Fetter wrote:
> >> Patch attached. If you think my changes are ok,
> >> please change the patch status to "Ready for Committer".
> >
> > Done :)
>
h. We don't want a repeat of the "last-minute
giant change" anti-pattern, and even if we're releasing 9.1 in July,
three months plus is plenty of time to shake things out.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfett
resumably, you're going to
> want to comb through the data to find out exactly what has gone wrong
> for each violation. On the off chance that it actually is a problem,
> the user can go ahead and write their own query, like Robert
> suggested.
Perhaps the errhint could suggest
the number out of the control file? Or even
> more to the point, since when do we need version numbers in extensions?
We *absolutely* need version numbers in extensions. People will want
to have a certain version, or a certain minimum version, etc., etc.,
etc., just as they do for any other soft
On Wed, Dec 08, 2010 at 01:23:59PM +0200, Marko Tiikkaja wrote:
> On 2010-12-08 10:19 AM +0200, David Fetter wrote:
> >On Sun, Dec 05, 2010 at 01:33:39PM -0500, Greg Smith wrote:
> >>So this patch was marked "Ready for Committer", but a) no committer
> >>has p
ough from someone like David might be
> appropriate to build some confidence this latest patch should be a
> commit candidate. If there is a committer intending to work on this
> as-is, they haven't identified themselves.
I've tested this one and not managed to break it. One thi
On Sat, Dec 04, 2010 at 09:27:52PM +0800, Boxuan Zhai wrote:
> Dear Greg,
>
> I have updated the MERGE patch for two main problems.
Please attach the actual patch :)
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: da
't there.
If we can teach the database things like, "the foo and bar columns are
guaranteed never to overlap among the partitions," it should be
possible make uniqueness guarantees over sets of partitions without
using a common index.
Cheers,
David.
--
David Fetter http:
On Wed, Dec 01, 2010 at 10:15:38AM -0600, Kevin Grittner wrote:
> David Fetter wrote:
>
> > Would the people now developing the JDBC driver object to
> > switching to git?
>
> If we move to git, don't forget that there is not one repository
> which has the en
> that one? Being able to work like that would make things a lot easier
> to review.
>
> That said, such a process would also be a lot easier if the JDBC
> driver wasn't in cvs ;)
This brings up an excellent point. Would the people now developing
the JDBC driver object to swi
My point exactly. You started off with high negativity, and you
should not expect good results from same.
Cheers,
David.
On Wed, Dec 01, 2010 at 08:15:25PM +0500, ghatpa...@vsnl.net wrote:
> Be positive ... Negative thoughts are not good...
>
> - Original Message -
> From:
On Wed, Dec 01, 2010 at 03:19:32PM +0500, ghatpa...@vsnl.net wrote:
> Hello,
>
> Here is the proposal: My 1st step towards Intelligent, Integrated database.
You're implying that databases are stupid and incoherent. This is
*not* a great way to start.
Cheers,
David.
--
Davi
On Tue, Nov 30, 2010 at 08:13:37PM +0900, Itagaki Takahiro wrote:
> On Tue, Nov 30, 2010 at 18:18, David Fetter wrote:
> >> It expands all tables (and views) in tab-completion after INSERT,
> >> UPDATE, and DELETE FROM. Is it an intended change?
>
> I found i
On Tue, Nov 30, 2010 at 05:48:04PM +0900, Itagaki Takahiro wrote:
> On Wed, Nov 24, 2010 at 12:21, David Fetter wrote:
> > Please find attached a patch changing both this and "updateable" to
> > "updatable," also per the very handy git grep I just learned abou
> Branch: master Release: REL6_1 [aaeef4d17] 1996-11-10 03:06:38 +
>
> I think it's quite foolish to depend on abbreviated hashes to be unique
> forever.
Good point. While a full-hash collision is of course possible, we
have much more likely things that can mess us up than t
m going to mark this as ready for a committer.
> >
> > I think we need more discussions about the syntax: ALTER TABLE
> > table_name ADD PRIMARY KEY (...) WITH (INDEX='index_name')
>
> Why not:
>
> ALTER TABLE table_name ADD PRIMARY KEY (...) INDEX index_
On Wed, Nov 24, 2010 at 11:01:28PM -0500, Josh Kupershmidt wrote:
> On Tue, Nov 23, 2010 at 10:21 PM, David Fetter wrote:
> > Please find attached a patch changing both this and "updateable" to
> > "updatable," also per the very handy git grep I just learned a
which have been split from "SQL/MED" patch. Can
> I add them to CF 2010-11 which original "SQL/MED" item is in? Or
> should I add them to CF 2011-01?
The original.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfett
On Tue, Nov 23, 2010 at 09:37:57PM -0500, Josh Kupershmidt wrote:
> On Fri, Oct 29, 2010 at 10:33 AM, David Fetter wrote:
> > That seems like a matter for a separate patch. Looking this over, I
> > found I'd created a query that can never get used, so please find
> > en
801 - 900 of 2082 matches
Mail list logo
