[ lots of opinions about depending on symlinks for tablespaces ]
One thing that I think hasn't been noted in this thread is that our
initial implementation won't bind us forever. If it becomes clear that
a symlink-based implementation has real problems, we can change it.
But if we spend extra eff
Steve Crawford wrote:
Please, don't call it 7.3.6. Streamlining releases is terrible.
7.3.7 or 7.3.6.1 or SOMETHING other than 7.3.6, and just let
7.3.6 be a brown paper bag release (like 6.4.1 was).
There were no code-change differences in this rewrap, so I see no
real need to change the version
Andrew Sullivan wrote:
> On Fri, Mar 05, 2004 at 06:26:52PM -0500, Bruce Momjian wrote:
> >
> > This is an item that needs clarification, as I mentioned.
>
> Yes, you certainly did. I apologise, I'm being unusually stupid
> today.
I looked again and the text mentioned statistics, but my comment
On Fri, Mar 05, 2004 at 06:26:52PM -0500, Bruce Momjian wrote:
>
> This is an item that needs clarification, as I mentioned.
Yes, you certainly did. I apologise, I'm being unusually stupid
today.
--
Andrew Sullivan
---(end of broadcast)---
TI
Andrew Sullivan wrote:
> On Fri, Mar 05, 2004 at 03:00:18PM -0500, Bruce Momjian wrote:
> > _
> >
> > Migration to version 7.4.2
> >
> >A dump/restore is *not* required for those running 7.4.X.
> > _
Dennis Haney <[EMAIL PROTECTED]> writes:
>> Joining {b,c} to {a} does not meet any of those four allowed cases.
>>
> Exactly my point... So why ever bother creating the {b,c} node which is
> legal by the above definition?
We don't, because there is no such join clause.
r
Tom Lane wrote:
Dennis Haney <[EMAIL PROTECTED]> writes:
Consider this example:
SELECT * FROM a,b WHERE a.id = b.id AND (a.id) IN (SELECT c.id FROM c)
the possible execution trees are {{a,b}, {c}}, {{a,c},{b}} and the code
seems to also permit {{b,c},{a}}.
No, it does
On Fri, Mar 05, 2004 at 03:00:18PM -0500, Bruce Momjian wrote:
> _
>
> Migration to version 7.4.2
>
>A dump/restore is *not* required for those running 7.4.X.
> __
Dennis Haney <[EMAIL PROTECTED]> writes:
> Consider this example:
> SELECT * FROM a,b WHERE a.id = b.id AND (a.id) IN (SELECT c.id FROM c)
> the possible execution trees are {{a,b}, {c}}, {{a,c},{b}} and the code
> seems to also permit {{b,c},{a}}.
No, it does not --- as you say, that would give
Here are the 7.4.2 release notes I made. I have a few question:
What detail do we need on the pg_statistics alignment fix? Do we need
to show an UPDATE query to fix database? What are the ramifications of
leaving it alone?
A few categories list "various fixes" for rare fixes we made in a few
"Thomas Swan" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
[snip]
> Apparently, I have failed tremendously in addressing a concern. The
> question is does PostgreSQL need to rely on symlinks and will that
> dependency introduce problems?
>
> There is an active win32 port underway (see
Quoting Bruce Momjian <[EMAIL PROTECTED]>:
> Zeugswetter Andreas SB SD wrote:
> > My idea for platforms that don't support symlinks would be to simply
> create
> > a tblspaceoid directory inplace instead of the symlink (maybe throw a
> warning).
> > My feeling is, that using the same syntax on such
Hi
I have a problem understanding the code to make certain in join are
performed properly. Specifically I have problems understading when
IN_UNIQUE_{INNER,OUTER} is a valid jointype.
Its in joinrels.c:make_join_rel.
Consider this example:
SELECT * FROM a,b WHERE a.id = b.id AND (a.id) IN (SELE
On Fri, 5 Mar 2004, Thomas Swan wrote:
> [EMAIL PROTECTED] wrote:
>
> ><[EMAIL PROTECTED]> writes:
> >
> >
> >
> >>>[EMAIL PROTECTED] wrote:
> >>>
> >>>
> >"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> >
> >
> My feeling is that we need not suppor
On Thursday 04 March 2004 7:28 pm, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Please, don't call it 7.3.6. Streamlining releases is terrible.
> > 7.3.7 or 7.3.6.1 or SOMETHING other than 7.3.6, and just let
> > 7.3.6 be a brown paper bag release (like 6.4.1 was).
>
> There were
On Friday 05 March 2004 09:50 am, Mark Gibson wrote:
> How about in future, packaging it all up as a release candidate,
> (ie. 7.4.2-rc1) for a week or so before official final release,
We do this already for major versions. Maybe we should consider this for
minors too.
--
Lamar Owen
Director o
Mark Gibson wrote:
Are there any Gentoo users here?
Do you wish the PostgreSQL ebuild made use of SLOTS?
I've submitted a slotted ebuild for testing at:
http://bugs.gentoo.org/show_bug.cgi?id=42894
It's the first slotted ebuild i've attempted, so it may be total rubish!
But I have managed to get 7
Fabien COELHO wrote:
The current status of clients is that none of those I use will report
anything useful.
pgAdmin3's query tool will set a mark on the offending line.
Regards,
Andreas
---(end of broadcast)---
TIP 2: you can get off all lists
Zeugswetter Andreas SB SD wrote:
>
> > First of all, symlinks are a pretty popular "feature." Even Windows
> > supports what would be needed. Second of all, PostgreSQL will still
> > run on OSes without symlinks, tablespaces won't be available, but
> > PostgreSQL will still run. Since we are al
Tom Lane wrote:
Lamar Owen <[EMAIL PROTECTED]> writes:
Please, don't call it 7.3.6. Streamlining releases is terrible. 7.3.7 or
7.3.6.1 or SOMETHING other than 7.3.6, and just let 7.3.6 be a brown paper
bag release (like 6.4.1 was).
There were no code-change differences in this rewrap,
Thomas Swan wrote:
> >The fact of the matter is that PostgreSQL runs better on some
> >platforms than others, and it probably always will. Heck, as of
> >today, PostgreSQL is officially supported on the Gamecube. Does that
> >mean that the PostgreSQL developers should limit themselves to the
> >f
Fabien COELHO <[EMAIL PROTECTED]> writes:
>> In particular, we determined that the appropriate place for this sort of
>> thing is on the client side, not in the backend.
> The current status of clients is that none of those I use will report
> anything useful.
So fix the clients. We have been th
On Fri, Mar 05, 2004 at 12:47:23AM +0100, Jochem van Dieten wrote:
> >I personally don't think that a GUI tool should be the province of the
> >Slony project. Seriously. I think that Slony should focus on a
I very much agree with this, but this is Jan's baby, so I didn't say
anything. I have
Dear patchers,
New submission attempt, with new message wording. Also, the message is
only shown once, and the offending key component is not shown.
Have a nice day,
--
Fabien Coelho - [EMAIL PROTECTED]
costly_ri_notice.patch.gz
Description: Binary data
---(end of bro
> First of all, symlinks are a pretty popular "feature." Even Windows
> supports what would be needed. Second of all, PostgreSQL will still
> run on OSes without symlinks, tablespaces won't be available, but
> PostgreSQL will still run. Since we are all using PostgreSQL without
My idea for pla
On Friday 05 March 2004 07:51, Thomas Swan wrote:
>
> Apparently, I have failed tremendously in addressing a concern. The
> question is does PostgreSQL need to rely on symlinks and will that
> dependency introduce problems?
>
> There is an active win32 port underway (see this mailing list). One
>
> > (2) Does someone has any comment about these problems or
> > the way I intend to try to address them?
>
> About the implementation idea with hints. I'm not sure will be so easy to
> implement as you suggested. Maybe if one add hints to every construct,
> and set to empty hint where it does
> > (1) Lexical/syntax error source localisation
>
> > An extract of the offending source must be shown if possible along syntax
> > error messages.
>
> You would do well to go to the archives and read some of the previous
> discussion of these issues.
I'll do that.
> In particular, we determine
28 matches
Mail list logo
