He does ask a legitimate question though. If you are
going to have a
LIMIT feature (which of course is not pure SQL), there
seems no reason
you shouldn't be able to insert the result into a table.
This is an interesting idea. We don't allow ORDER BY in
INSERT INTO ...
we bite the bullet to the extent of supporting a distinction between
physical and logical column numbers, then ISTM there's no strong need
to do any of this other stuff at all. I'd expect that an inserted or
updated tuple would have a NULL in any physical column position that
doesn't have
[ Charset ISO-8859-1 unsupported, converting... ]
we bite the bullet to the extent of supporting a distinction between
physical and logical column numbers, then ISTM there's no strong need
to do any of this other stuff at all. I'd expect that an inserted or
updated tuple would have a
On Thu, 12 Oct 2000, Mikheev, Vadim wrote:
Could this be added? I am willing to help with the coding.
This is what Version 7.1 WAL is all about.
There might be some help wanted in one of the possible backup methods:
1. a pg_dumpall restore, and a subsequent restore of logs
On Fri, 13 Oct 2000, Bruce Momjian wrote:
[ Charset ISO-8859-1 unsupported, converting... ]
we bite the bullet to the extent of supporting a distinction between
physical and logical column numbers, then ISTM there's no strong need
to do any of this other stuff at all. I'd expect that
Hiroshi's patch would make for a good starting point by bringing in the
ability to do the DROP COLUMN feature, as I understand, without the
rollback capability,
No Hiroshi's patch is rollback enabled, simply because all it does is change
some system tables. It only does not free space that
Running postgres in -d 2 mode is a little frustrating on a server that
processes as little as 10 queries a second. Can we not add getpid() or
something to that code so that we might track which output belongs to
which server a little easier?
Thanks,
-Dan
--
Man is a rational animal who
On Tue, Oct 10, 2000 at 01:02:52PM -0400, Tom Lane wrote:
Bottom line is we're not sure what to do now. Opinions from the
floor, anyone?
First, I include my voice with those congratulating Bruce, and wishing
him the best of luck in his new position.
I concur that no one who has paid any
Dan Moschuk writes:
Running postgres in -d 2 mode is a little frustrating on a server that
processes as little as 10 queries a second. Can we not add getpid() or
something to that code so that we might track which output belongs to
which server a little easier?
If you're running
On Wed, Oct 11, 2000 at 02:40:47PM -0400, Bruce Momjian wrote:
On Wed, 11 Oct 2000, Bruce Momjian wrote:
Considering no one has used it in 4 years that I remember, my guess is
that it is an abandonded Berkeley project.
If it does not break anything in our build process, please let
What to do? Make as much communication as possible public. When in doubt,
err on the public side. Develop in the fish bowl. If you feel there still
a need for private channels, perhaps include some outside representative,
trusted by the community, who can serve as a witness of record, if you
On Fri, Oct 13, 2000 at 04:10:48PM -0400, Bruce Momjian wrote:
We were talking about this today down here at Great Bridge, and I
mentioned that there is very little that happens in the core group. Up
until Great Bridge arrived, and we had to secretly communicate with
them, there really
On Fri, 13 Oct 2000, Zeugswetter Andreas SB wrote:
Hiroshi's patch would make for a good starting point by bringing in the
ability to do the DROP COLUMN feature, as I understand, without the
rollback capability,
No Hiroshi's patch is rollback enabled, simply because all it does is
Bruce Momjian [EMAIL PROTECTED] writes:
This said, I think Hiroshi's patch seems a perfect starting point, no ?
Having phantom columns adds additional complexity to the system overall.
We have to decide we really want it before making things more complex
than they already are.
I think we
The Hermit Hacker [EMAIL PROTECTED] writes:
okay, but, again based on my impression of what Tom has stated, and
previous conversations on this topic, the key problem is what happens if I
drop a column and a later date decide add a new column of the same name,
what happens?
I'm not very
On Fri, 13 Oct 2000, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
okay, but, again based on my impression of what Tom has stated, and
previous conversations on this topic, the key problem is what happens if I
drop a column and a later date decide add a new column of the
Philip Warner [EMAIL PROTECTED] writes:
When someone devotes hours of time to PGSQL for no recompense, their
motives are generally not questioned. So when someone makes a design
decision, the motive is assumed to be because it is best in the long term
for the project. As soon as someone is
On Fri, Oct 13, 2000 at 10:54:31PM -0400, Bruce Momjian wrote:
Man, Tom, our cover is working perfectly. Let's disagree on something
again. That will really convince them. :-)
This was supposed to go to -core, right? (I see Bruce got my joke. I
wasn't so sure Tom did ...)
Tom
Hi!
On Wed, 23 Aug 2000, Tom Lane wrote:
Yes, we know about that one. We have stats about the most common value
in a column, but no information about how the less-common values are
distributed. We definitely need stats about several top values not just
one, because this phenomenon
On Sat, 14 Oct 2000, Bruce Momjian wrote:
On Mon, 21 Aug 2000, Tom Lane wrote:
One thing it might be interesting (please tell me if you think
otherwise) would be to improve pg with better statistical information, by
using, for example, histograms.
Yes, that's been on
20 matches
Mail list logo
