> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > For example: the datatypes have different names; the set of reserved
> > > words is different; Oracle uses a weird syntax for outer joins.
> >
> > Is it really possible to fix these things strictly in
Hi guys,
Not sure if Peter was joking, but Ian's approach sounds much more
user-friendly.
Getting Oracle users to convert to PostgreSQL then be "stuck-with-it"
because they can't afford the migration elsewhere is not the right
approach.
PostgreSQL is a really good product, and the best way to e
On Mon, 13 Aug 2001, Justin Clift wrote:
> Hi guys,
>
> Not sure if Peter was joking, but Ian's approach sounds much more
> user-friendly.
>
> Getting Oracle users to convert to PostgreSQL then be "stuck-with-it"
> because they can't afford the migration elsewhere is not the right
> approach.
If
On Sun, Aug 12, 2001 at 10:21:55PM -0400, Vince Vielhaber wrote:
>
> If you think that people are going to flock to PostgreSQL from Oracle
> simply because it's a drop in replacement, I want some of whatever it
> is you're drinking!
>
> An Oracle compatibility mode wouldn't be a bad idea, but at
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> An Oracle compatibility mode wouldn't be a bad idea, but at what cost
> and at how much effort?
That is why I focused on the relatively minor changes to Postgres
required to hook in an alternate parser. I personally would not
expect the mainline Pos
Hi Vince,
The point I'll make is this :
People who presently have installations on Oracle will be more inclined
to test/trial PostgreSQL if they know the learning curve is much less
than say, migrating to DB2 would be (or some other database without
specific Oracle-transition compatibilities).
Jan Wieck <[EMAIL PROTECTED]> writes:
> files per parser and call the right one from tcop. Now for
> some flex/bison combo's at least the prefix switches (to have
> something different than YY) don't work reliable. There will
> be some global YY-objects left, causing linkag
Jan Wieck <[EMAIL PROTECTED]> writes:
> If we want to have both parsers available at runtime we need
> to replace the YY (case-insensitive) prefix in the generated
> files per parser and call the right one from tcop. Now for
> some flex/bison combo's at least the prefix switc
Tom Lane <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > ... most of the cost will be paid by the people who care about
> > it. (Not all of the cost, because some communication will be required
> > when the parse tree nodes are changed.)
>
> > Along these lines, I
Ian Lance Taylor writes:
> I'm not sure what you mean by managing grammar changes, although
> perhaps I am reading too much into that. The Oracle grammar is set by
> Oracle, and will not change even if the Postgres grammar changes.
Things like VACUUM and ANALYZE, which you will have to keep unl
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Things like VACUUM and ANALYZE, which you will have to keep unless you
> want to implement an Oracle storage manager as well. ;-)
Evidently Ian is just interested in a parser that could be used by
Oracle-compatible applications, which'd not be invoki
Ian Lance Taylor wrote:
> Along these lines, I don't think Bruce's suggestion of modifications
> to the Postgres gram.y is a good idea, because it causes the Oracle
> parser to add an ongoing cost to the Postgres parser.
Bruce, Tom and I discussed these issues during our time in
San Di
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> ... most of the cost will be paid by the people who care about
> it. (Not all of the cost, because some communication will be required
> when the parse tree nodes are changed.)
> Along these lines, I don't think Bruce's suggestion of modifications
>
I sent the list a message a little while ago about what I do with postgres.
I thought, after all this discussion, that it might be important to send a
further message to the list indicating why I chose not to use Oracle.
I'm going to go out on a limb and say that I have one of the largest
postgre
14 matches
Mail list logo
