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
Included is a example program appears in our docs (libpq.sgml).
As you can see, the very last part of the program:
PQfinish(conn);
return 0;
never execute. Should we remove them?
--
Tatsuo Ishii
main()
{
char *pghost,
*pgport,
*pgoptions,
I made the following patch, and it works for MY platform.
Peter,
Can we do something similar for the distribution to set the
RUNPATH for Pg.so?
Index: Makefile.PL
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces
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
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Does this mean there should be a regression test for binary cursors then...?
Sure, if you can think of a portable way to do it.
regards, tom lane
---(end of broadcast)
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> CREATE FUNCTION myftest(INT)
> RETURNS INT
> AS '
> UPDATE t1 SET i = 1 WHERE i = 1;
> COPY t1 TO ''/tmp/t1.data'';
> SELECT i FROM t1 WHERE i = (SELECT i FROM t1 WHERE i = 1);
> '
> LANGUAGE 'sql';
> When COPY is invoked in the function, I thoug
> No we don't. There are no SetQuerySnapshot calls occuring *within*
> a query. An example of why that would be unacceptable: consider
>
> select myfunc(f1) from table where f2 = 42;
>
> Suppose executing myfunc() causes an unrestored SetQuerySnapshot call.
> Then, if other transactions
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> BTW, why must we restore the previous QuerySnapshot? We already break
> the rule (if it's a rule).
No we don't. There are no SetQuerySnapshot calls occuring *within*
a query. An example of why that would be unacceptable: consider
select myfunc
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
Rene Pijlman <[EMAIL PROTECTED]> writes:
> So it appears that your new statement that uses
> obj_description() and col_description() returns one row with a
> null when there is no comment, instead of 0 rows. Is this
> intentional?
That is how selecting a function result would work. If you don't
Does this mean there should be a regression test for binary cursors then...?
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane
> Sent: Saturday, 11 August 2001 4:19 AM
> To: Jan Wieck
> Cc: [EMAIL PROTECTED]
> Subject: [HACKERS] Portal
> > One way to make the results equivalent is to compute a new QuerySnapshot
> > for each SPI query. Quite aside from the cost of doing so, I do not
> > think it makes sense, considering that the previous QuerySnapshot must
> > be restored when we return from the function. Do we really want
> >
Tom Lane <[EMAIL PROTECTED]> writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think we are on hold for Hiroshi, right?
>
> Yes. I believe I know which patch he's referring to --- it's the only
> change in src/backend/utils/adt/tid.c since 7.1. If he hasn't committed
> in a few hours I
On Fri, 10 Aug 2001 16:08:50 -0400, you wrote:
>The problem is in DatabaseMetaData.java (same code in both jdbc1 and
>jdbc2, looks like). It does direct access to pg_description that isn't
>right anymore. In getTables, instead of
>
> java.sql.ResultSet dr = connection.ExecSQL("select descr
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
> 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
Justin Clift wrote:
> If you finalise this into a decent procedure (and/or scripts), then
> would you mind contributing them? I can place them on the
> techdocs.postgresql.org website as a start.
>
Not at all, I plan to contribute any/all work I am
involved with. This would be part of valid
17 matches
Mail list logo
