On Sat, Jul 03, 2004 at 11:03:33AM -0400, Tom Lane wrote:
> TransactionIdIsInProgress needs work/review; comments are off for one
> thing, and it seems *way* too inefficient. Note it should be possible to
> skip subtrans search for sufficiently old xacts (hm ... couldn't we skip
> sinval search t
Mario Weilguni wrote:
Because their SQL queries always seem to need a target object to select
from. i.e. "SELECT NEXTVAL.foo" isn't valid for Oracle 8/9.
It has been a long time since I've used Oracle, but shouldn't it be "select foo.nextval from dual"?
Yep, that's sounds better. It's been a co
>
> Because their SQL queries always seem to need a target object to select
> from. i.e. "SELECT NEXTVAL.foo" isn't valid for Oracle 8/9.
>
It has been a long time since I've used Oracle, but shouldn't it be "select
foo.nextval from dual"?
Regards,
Mario Weilguni
---
Alvaro Herrera wrote:
One generalization of this to nested transactions would be:
SUBBEGIN [transactionname]
SUBCOMMIT [transactionname]
SUBABORT [transactionname]
The only departure from the SAVEPOINT syntax is that you are able to
"subcommit" a savepoint. Not sure how useful that is ...
One thi
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Do you get where I'm coming from with this?
> Yes, but I disagree.
Same here. The portable information already is in information_schema,
and I don't really see that it's better to find unportable information
in information_schema views than
One other benefit of having more stuff in information_schema.* is that
the stuff there is "easier" to look at and figure out what it is. With
the view definitions that are provided to things like psql and pgAdmin
when people look at an information_schema view, it provides them a way
of figurin
Christopher Kings-Lynne wrote:
There's a whole lot of difference between the skill level needed to
query the information_schema and find out things like table and column
names, vs looking into pg_namespace, pg_class and pg_attribute plus
understanding the specific info there to work out table an
On Mon, Jul 05, 2004 at 03:38:13PM +1200, Oliver Jowett wrote:
> As I just mentioned in another thread, whatever the syntax for nested
> transactions I'd like to see plain COMMIT/ABORT/ROLLBACK always affect
> the top-level transaction.
>
> Oracle appears to have:
>
> SAVEPOINT savepointname
There's a whole lot of difference between the skill level needed to
query the information_schema and find out things like table and column
names, vs looking into pg_namespace, pg_class and pg_attribute plus
understanding the specific info there to work out table and column names.
I reckon that
Christopher Kings-Lynne wrote:
Anyone who's writing queries that are examing the schema of the database
is by definition not a newbie...
By newbie here, I mean someone who's a PG "newbie" but has a reasonable
understanding of databases (i.e. Oracle, etc) would generally find the
"information_sc
[ BCC to hackers.]
I just returned from a twelve day trip to Germany and Armenia. LinuxTag
in Germany was a big success. We had our own booth and lot of people
came to talk to us. The things users asked about (nested transactions,
replication, PITR, Win32) are already being working on so I fee
Tom Lane wrote:
Still need to agree about externally visible behavior (a different stmt
than begin/commit for subxacts? What about savepoints?) Also, what about
exposing this functionality in plpgsql? Seems like we need some kind of
exception handling syntax to make this useful. What does Oracl
My take on this is that it's a LOT easier for people who don't know the
internals of the PG catalogs to be able to query the information schema,
as in the information schema things are generally explicitly named.
Much easier for non-experts, which most people don't want to have to
invest the ti
Greg Stark wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
If we change the syntax, say by using SUBCOMMIT/SUBABORT for
subtransactions, then using a simple ABORT would abort the whole
transaction tree.
This seems like a non-starter to me. That would make it impossible to write
SQL generic code
Justin Clift <[EMAIL PROTECTED]> writes:
> There's also their "FROM DUAL" workaround (in common usage) as well.
[ yawn... ]
regression=# create table dual();
CREATE TABLE
regression=# insert into dual default values;
INSERT 292940 1
regression=# select 2+2 from dual;
?column?
--
Christopher Kings-Lynne wrote:
Well, if we add them (and they would be very useful I reckon) should
we ensure there's an obvious PG naming thing happening?
Why are they useful If you want PG specific stuff then use the PG
specific catalogs!!!
My take on this is that it's a LOT easier for peop
The README.spi said that $rv->{rows} should return the number of
rows affected for INSERT, UPDATE & DELETE. It seems to return NULL.
@{$rv->{rows}} also returns NULL.
-- drop table users ( email text, who text );
create table users ( email text, who text );
insert into users values ('[EMAIL PRO
Andreas Pflug wrote:
That's true, it's the question how much can be offered without too much
effort.
I'm not too deep in oracle stuff, what comes to my mind is
- outer join syntax (parser thing)
- sequences usage (parser too)
- maybe stored procedure call, with a wrapper to convert output
parame
--
-- An SQL error causes subsequent function creation of an otherwise
-- healthy function to fail WHEN RUN with:
--ERROR: creation of function failed:
--(in cleanup) Undefined subroutine &PLPerl::mksafefunc called at (eval 4) line 4.
--
-- Workaround is to close and reopen the connection
> That's right, and initially they will only serve MySQL, but it will be
> extendable to support any db system. It will be GPL (or licenseable, but
> since it's a tool and not a platform IMHO GPL is ok).
> If things work out as they seem, I'd contribute the pgsql stuff.
That would be great news in
Jeroen T. Vermeulen wrote:
On Sun, Jul 04, 2004 at 02:33:53PM +1200, Oliver Jowett wrote:
Consider SET client_encoding then..
Does that really affect most middleware? In my situation for instance,
what goes through the connection either way is "just bytes" to the
middleware. Its interpretatio
Ok. It's impossible for me to fix this by remote control - I need access
to some box with one of these old versions of perl so I can come up with
a clean solution.
Or did you revert the change that put "#include ppport.h" in SPI.xs?
cheers
andrew
Bruce Momjian wrote:
Andrew Dunstan wrote:
Tha
Andrew Dunstan wrote:
>
> That is *intensely* annoying. What on earth are these function bodies
> doing in a .h file anyway? (Remember, I just used the standard utility
> to generate the file).
>
> Anyway, here is a version with all that stuff cut out - I don't believe
> we need any of it. Doe
On Sun, Jul 04, 2004 at 06:39:46PM -, Greg Sabino Mullane wrote:
> > There's no actual extra parsing involved, as far as I can see, just
> > pattern matching and the extraction of the variables.
>
> That sounds like "parsing" to me. :)
Depends on your definition, I guess. I would say v
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeroen T. Vermeulen wrote:
> There's no actual extra parsing involved, as far as I can see, just
> pattern matching and the extraction of the variables.
That sounds like "parsing" to me. :)
[client handling the tracking of PREPARE names]
> In
On Sun, Jul 04, 2004 at 12:10:52AM -0400, Alvaro Herrera wrote:
> You made me remember that some time ago a non-tech fellow presented me
> as giving a talk about "Postgresol" ... the audience had quite a laugh.
> It seems nobody thought about instructing him on how to pronounce the
> thing ... it
Andrew Dunstan wrote:
>
> The problem is your old version of perl.
>
> Please see if the attached patch fixes it (The one I sent in previously
> didn't apply cleanly - this one should).
With your patch I now get this failure:
gmake[4]: Leaving directory
`/usr/var/local/src/gen
On Sun, Jul 04, 2004 at 02:33:53PM +1200, Oliver Jowett wrote:
> Consider SET client_encoding then..
Does that really affect most middleware? In my situation for instance,
what goes through the connection either way is "just bytes" to the
middleware. Its interpretation is a client matter. So
[ BCC to general and hackers.]
Here is a great PostgreSQL article that appeared recently. It
highlights companies supporting PostgreSQL and our upcoming 7.5
features:
http://software.newsforge.com/software/04/07/01/0721222.shtml?tid=72&tid=82
(I have submitted it to our News web page.)
Bruce Momjian wrote:
Andreas Pflug wrote:
Jeroen T. Vermeulen wrote:
But like I said, that's just my personal conviction. I definitely think
people in our community ought to be willing to work together with the
MySQL people, the FireBird people and anybody else in the free world to
have wo
I am getting a CVS HEAD compile failure in plperl:
gmake[4]: Leaving directory
`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/pl/tcl/modules'
gmake[3]: Leaving directory
`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/pl/tcl'
gmake[3]: Entering directory
`/usr/v
Andreas Pflug wrote:
> Jeroen T. Vermeulen wrote:
>
> >
> >But like I said, that's just my personal conviction. I definitely think
> >people in our community ought to be willing to work together with the
> >MySQL people, the FireBird people and anybody else in the free world to
> >have world-clas
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
How about an external tool that helps in translating apps to
SQL-standard syntax? Oracle does accept the standard syntax after all.
Nice idea, but
- sources might not be accessible
- sources might not be easily readable (esp. i
Jeroen T. Vermeulen wrote:
But like I said, that's just my personal conviction. I definitely think
people in our community ought to be willing to work together with the
MySQL people, the FireBird people and anybody else in the free world to
have world-class GUI development tools;
Just a note:
I'
34 matches
Mail list logo
