(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 determined that the
(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 not
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
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
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
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
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 through
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
features
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,
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 all using
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
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 of
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 no
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 support tablespaces on OS's without
symlinks.
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
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 platforms
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 this
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
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 wrong
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.
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
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.
regards,
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.
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)---
TIP
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 comments
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
[ 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
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
28 matches
Mail list logo
