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:
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. if
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-class GUI
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
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
[ 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=72tid=82
(I have submitted it to our News web page.)
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 to
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
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 was
-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 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 very
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. Does this
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:
That
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 interpretation
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
--
-- 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
Andreas Pflug wrote:
snip
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
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
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?
--
4
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
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
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
[ 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
Christopher Kings-Lynne wrote:
snip
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
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
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
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 figuring
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 in
28 matches
Mail list logo
