My opinion is that PostgreSQL should accept any MySQL syntax and return
warnings. I believe that we should access even innodb syntax and turn it
immediately into PostgreSQL tables. This would allow people with no
interest in SQL to migrate from MySQL to PostgreSQL without any harm.
A solution
On Sun, Mar 07, 2010 at 12:11:26PM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
I encountered a core dump running PL/Perl installcheck with a very
recent git HEAD of PostgreSQL and a not quite so recent git HEAD of perl.
The cause is a subtle difference between SvTYPE(sv)
On 2010-03-08 11:17 +0200, Pierre C wrote:
- index skip scans (well, MySQL doesn't really do index skip scans, but
since it can do index-only scans, it's an approximation)
As far as I can tell, we already do index skip scans:
= create index foo_a_b_idx on foo(a,b);
CREATE INDEX
= explain
As far as I can tell, we already do index skip scans:
This feature is great but I was thinking about something else, like SELECT
DISTINCT, which currently does a seq scan, even if x is indexed.
Here is an example. In both cases it could use the index to skip all
non-interesting rows,
On 2010-03-08 11:47 +0200, Pierre C wrote:
As far as I can tell, we already do index skip scans:
This feature is great but I was thinking about something else, like SELECT
DISTINCT, which currently does a seq scan, even if x is indexed.
Here is an example. In both cases it could use the
2010/3/7 Zdenek Kotala zdenek.kot...@sun.com:
Magnus Hagander píše v po 01. 03. 2010 v 16:55 +0100:
2010/3/1 Zdenek Kotala zdenek.kot...@sun.com:
Magnus Hagander píše v čt 25. 02. 2010 v 15:17 +0100:
On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala zdenek.kot...@sun.com
wrote:
Hi all,
2010/3/8 Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp:
Tom Lane t...@sss.pgh.pa.us wrote:
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
I'd like to propose to define PGALWAYSEXPORT macro:
#ifdef WIN32
#define PGALWAYSEXPORT __declspec (dllexport)
#endif
and
Oh, this is what I believe MySQL calls loose index scans. I'm
Exactly :
http://dev.mysql.com/doc/refman/5.0/en/loose-index-scan.html
actually looking into this as we speak,
Great ! Will it support the famous top-n by category ?
but there seems to be a
non-trivial amount of work to be
On Fri, Mar 5, 2010 at 3:14 AM, Josh Berkus j...@agliodbs.com wrote:
On 3/4/10 2:47 AM, Fujii Masao wrote:
This TODO item really needs to be addressed for 9.0? Frankly I'm not
familiar with that area, so I've not work on it at all yet, but I'm
going to create the patch if many people want it
On Mon, Mar 08, 2010 at 10:46:03AM +0900, Takahiro Itagaki wrote:
There is a complier warning in ecpg/ecpglib/error.c on HEAD:
...
Instead, should we use if (strcmp(...) == 0) here?
Exactly. Thanks for spotting this, fixed in HEAD.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De,
On Thu, Feb 25, 2010 at 7:48 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Feb 25, 2010 at 7:22 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Yeah. The current pg_*_last_location() functions don't cut it though,
you need to retain logs back to the redo location of
On Wed, Mar 03, 2010 at 07:01:56PM -0500, Andrew Dunstan wrote:
Joshua D. Drake wrote:
On Wed, 2010-03-03 at 11:33 -0500, Andrew Dunstan wrote:
Well, we could put in similar weasel words I guess. But after
all, Safe's very purpose is to provide a restricted execution
environment, no?
We
On Mon, Mar 8, 2010 at 1:39 AM, David Christensen da...@endpoint.com wrote:
On Mar 7, 2010, at 9:22 AM, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
2010/3/6 Tom Lane t...@sss.pgh.pa.us:
The analogy I was thinking about was psql -X, but I agree that it's
not obvious why
On Mon, Mar 8, 2010 at 4:58 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-03-08 11:47 +0200, Pierre C wrote:
As far as I can tell, we already do index skip scans:
This feature is great but I was thinking about something else, like SELECT
DISTINCT, which currently does a seq
+1
Isn´t that a good time to think to put that question into the list of things
PostgreSQL doesn´t want to do?
Cheers
Von: Andrew Dunstan and...@dunslane.net
An: francois.pe...@free.fr
CC: Josh Berkus j...@agliodbs.com; Craig Ringer
On Mon, Mar 8, 2010 at 9:48 AM, Wolfgang Wilhelm
wolfgang20121...@yahoo.de wrote:
+1
Isn´t that a good time to think to put that question into the list of things
PostgreSQL doesn´t want to do?
Yes.
...Robert
Von: Andrew Dunstan and...@dunslane.net
François Pérou wrote:
My opinion is
Robert Haas robertmh...@gmail.com wrote:
Wolfgang Wilhelm wolfgang20121...@yahoo.de wrote:
Isn*t that a good time to think to put that question into the
list of things PostgreSQL doesn*t want to do?
Yes.
Done.
http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want
-Kevin
--
On Mar 8, 2010, at 9:16 AM, Kevin Grittner wrote:
Robert Haas robertmh...@gmail.com wrote:
Wolfgang Wilhelm wolfgang20121...@yahoo.de wrote:
Isn*t that a good time to think to put that question into the
list of things PostgreSQL doesn*t want to do?
Yes.
Done.
Yes, I've seen quite a few of François's posts around on Drupal. Drupal
7 has an OO query building abstraction layer which _should_ address most
of the issues and differences between MySQL, PostgreSQL and SQLite
(newly supported in Drupal 7) because each driver can form the query
string
David Christensen da...@endpoint.com writes:
On Mar 8, 2010, at 9:16 AM, Kevin Grittner wrote:
Wolfgang Wilhelm wolfgang20121...@yahoo.de wrote:
Isn*t that a good time to think to put that question into the
list of things PostgreSQL doesn*t want to do?
Done.
Tim Bunce tim.bu...@pobox.com writes:
Here's a patch that:
1. adds wording like that to the docs.
2. randomises the container package name (a simple and sound security
measure).
3. requires Safe 2.25 (which has assorted fixes, including security).
4. removed a harmless but suprious
Tom Lane t...@sss.pgh.pa.us wrote:
I think the new item might be phrased a little too broadly. The
problem with mysql's GROUP BY behavior is not the syntax but the
nonstandard semantics, ie, that it will pick a random result row
when the query is underspecified.
I thought that some of the
On Mar 8, 2010, at 8:03 AM, Tom Lane wrote:
#3 is still an absolute nonstarter, especially for a patch that we'd
wish to backpatch.
You're at least going to want to exclude Safe 2.20 - 2.23, IIUC.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Mon, Mar 8, 2010 at 4:17 AM, Pierre C li...@peufeu.com wrote:
My opinion is that PostgreSQL should accept any MySQL syntax and return
warnings. I believe that we should access even innodb syntax and turn it
immediately into PostgreSQL tables. This would allow people with no
interest in SQL
On Mon, Mar 08, 2010 at 11:58:20AM -0500, Jaime Casanova wrote:
On Mon, Mar 8, 2010 at 4:17 AM, Pierre C li...@peufeu.com wrote:
My opinion is that PostgreSQL should accept any MySQL syntax and
return warnings. I believe that we should access even innodb
syntax and turn it immediately
2010/3/9 Jaime Casanova jcasa...@systemguards.com.ec:
On Mon, Mar 8, 2010 at 4:17 AM, Pierre C li...@peufeu.com wrote:
My opinion is that PostgreSQL should accept any MySQL syntax and return
warnings. I believe that we should access even innodb syntax and turn it
immediately into PostgreSQL
David E. Wheeler da...@kineticode.com writes:
On Mar 8, 2010, at 8:03 AM, Tom Lane wrote:
#3 is still an absolute nonstarter, especially for a patch that we'd
wish to backpatch.
You're at least going to want to exclude Safe 2.20 - 2.23, IIUC.
If those aren't versions that are likely to be in
On Mon, Mar 8, 2010 at 12:10 PM, David Fetter da...@fetter.org wrote:
On Mon, Mar 08, 2010 at 11:58:20AM -0500, Jaime Casanova wrote:
On Mon, Mar 8, 2010 at 4:17 AM, Pierre C li...@peufeu.com wrote:
My opinion is that PostgreSQL should accept any MySQL syntax and
return warnings. I believe
On Mon, Mar 08, 2010 at 11:03:27AM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
Here's a patch that:
1. adds wording like that to the docs.
2. randomises the container package name (a simple and sound security
measure).
3. requires Safe 2.25 (which has assorted fixes,
On Mar 8, 2010, at 9:14 AM, Tom Lane wrote:
If those aren't versions that are likely to be in wide use, no objection
to that.
Yes, those are a series of releases in the last couple of months that had one
level of brokenness or another I'm going to test 2.25 today.
I'm just concerned about
On Mon, Mar 08, 2010 at 12:18:31PM -0500, Robert Haas wrote:
On Mon, Mar 8, 2010 at 12:10 PM, David Fetter da...@fetter.org wrote:
On Mon, Mar 08, 2010 at 11:58:20AM -0500, Jaime Casanova wrote:
On Mon, Mar 8, 2010 at 4:17 AM, Pierre C li...@peufeu.com wrote:
My opinion is that
2010/3/8 David E. Wheeler da...@kineticode.com:
Particularly if the vendor chooses to back-patch
Safe security fixes without bumping the visible version number, as is
not unlikely for Red Hat in particular.
This is why I hate packaging systems. Frankly, Red Hat's Perl has been
consistently
On Mon, Mar 8, 2010 at 12:43 PM, David Fetter da...@fetter.org wrote:
On Mon, Mar 08, 2010 at 12:18:31PM -0500, Robert Haas wrote:
On Mon, Mar 8, 2010 at 12:10 PM, David Fetter da...@fetter.org wrote:
On Mon, Mar 08, 2010 at 11:58:20AM -0500, Jaime Casanova wrote:
On Mon, Mar 8, 2010 at 4:17
Robert Haas wrote:
You do know that SQL is Turing-complete, right?
That seems largely irrelevant to the problem at hand. It's not
impossible to do syntactic transformations from one Turing-complete
langauge to another; if it were, there could be no such thing as a
compiler.
If
On Mon, Mar 8, 2010 at 09:03, Tom Lane t...@sss.pgh.pa.us wrote:
Tim Bunce tim.bu...@pobox.com writes:
3. requires Safe 2.25 (which has assorted fixes, including security).
#3 is still an absolute nonstarter, especially for a patch that we'd
wish to backpatch.
FWIW I think its a given you
Alex Hunsaker bada...@gmail.com writes:
That being said I would be in favor of at least saying Hey! your
using a known broken version of Safe. Maybe something like the below
at pl_perl init time? (That is instead of requiring v2.25 just
complain about older versions)
elog(WARNING, Safe
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I thought that some of the items on the OP's list were requests to
add an alternative syntax for an existing feature, without a change
in semantics. Did I misunderstand that? If not, is it something we
want to consider?
I think the
So, if php dev doesn't have time to learn to do things right then we
have to find time to learn to do things wrong? seems like a nosense
argument to me
The best ever reply I got from phpBB guys on I don't remember which
question was :
WE DO IT THIS WAY BECAUSE WE WANT TO SUPPORT MYSQL 3.x
On Mon, Mar 8, 2010 at 10:14, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
On Mar 8, 2010, at 8:03 AM, Tom Lane wrote:
#3 is still an absolute nonstarter, especially for a patch that we'd
wish to backpatch.
You're at least going to want to exclude Safe
Tom Lane t...@sss.pgh.pa.us wrote:
I believe we do have consensus that we aren't interested in
adopting MySQL's nonstandard GROUP BY semantics. I don't recall
what else there might be a definite no for.
TODO not wanted entry rewritten to address just this one issue.
The other issues
On Sun, 2010-03-07 at 16:37 +0100, Magnus Hagander wrote:
With your interleave, you mean things like psql -f first.sql -f - -f
second.sql? That does sound like it could be handy - and also really
dangerous :-)
Multiple -f support would be a good thing.
As would mixed -f and -c options.
What
Tom Lane wrote:
Yes, I think we should narrowly list things we don't want to do.
The current wording reads like we aren't interested in adopting any
MySQL ideas, which I don't think is actually the project consensus,
not to mention that it doesn't look good from a PR standpoint.
Indeed.
Hi,
Every often, i analyze logs to find most slow queries... and every
time i found myself trying to ignore pg_dump's generated COPY commands
which could be very expensive...
can we add a parameter in pg_dump and pg_dumpall to disable
log_min_duration_statement?
--
Atentamente,
Jaime Casanova
Kevin Grittner kevin.gritt...@wicourts.gov writes:
TODO not wanted entry rewritten to address just this one issue.
The other issues raise in the original post are valid possible
enhancements, or is there something else to list?:
http://archives.postgresql.org/pgsql-hackers/2010-03/msg00257.php
Jaime Casanova jcasa...@systemguards.com.ec writes:
can we add a parameter in pg_dump and pg_dumpall to disable
log_min_duration_statement?
export PGOPTIONS=-c log_min_duration_statement=-1
Or use ALTER USER SET to add that to the options for the account
you do pg_dump with; etc etc.
On Mon, Mar 8, 2010 at 4:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova jcasa...@systemguards.com.ec writes:
can we add a parameter in pg_dump and pg_dumpall to disable
log_min_duration_statement?
export PGOPTIONS=-c log_min_duration_statement=-1
ah! so, that is PGOPTIONS for :)
On Sat, 2010-01-02 at 20:51 -0500, Andrew Dunstan wrote:
Andrew Dunstan wrote:
I think the plperl glue code should check returned strings using
pg_verifymbstr().
Please test this patch. I think we'd probably want to trap the encoding
error and issue a customised error message,
Jaime Casanova wrote:
On Mon, Mar 8, 2010 at 4:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova jcasa...@systemguards.com.ec writes:
can we add a parameter in pg_dump and pg_dumpall to disable
log_min_duration_statement?
export PGOPTIONS=-c log_min_duration_statement=-1
ah!
Bruce Momjian wrote:
BBruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
The attached patch checks for the proper return from BEGIN/COMMIT, and
properly frees the libpq structures. In testing, this does return 3 as
you expected.
Really? It looks
Bruce Momjian br...@momjian.us writes:
I thought some more about it and realized I had to check for the
on-error-exit flag too. Updated patch attached.
Applied.
Shouldn't that be back-patched?
regards, tom lane
--
Sent via pgsql-hackers mailing list
Hannu Krosing ha...@2ndquadrant.com writes:
So SPI interface should also be fixed, either from perl side, or maybe
from inside SPI ?
SPI has every right to assume that data it's given is already in the
database encoding.
regards, tom lane
--
Sent via pgsql-hackers
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I thought some more about it and realized I had to check for the
on-error-exit flag too. Updated patch attached.
Applied.
Shouldn't that be back-patched?
Uh, well, it is going to change the behavior of back branches, and
because
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Shouldn't that be back-patched?
Uh, well, it is going to change the behavior of back branches, and
because we only got one report of the bug which has existed since 8.2, I
didn't want to risk it. Should I?
I would say that the odds of
On 03/05/2010 10:28 AM, Greg Smith wrote:
Heikki Linnakangas wrote:
Then again, if you don't use the copy in shared memory but just open the
pg_control file and read it in the UDF, you could implement this as a
pgfoundry module that works with older versions too.
This is the direction I'd
On Sat, Mar 6, 2010 at 12:13 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The REDO location of last checkpoint might deserve a function of its
own, like we have pg_last_xlog_replay_location() and
pg_last_xlog_receive_location().
Agreed. I submitted the patch which
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Shouldn't that be back-patched?
Uh, well, it is going to change the behavior of back branches, and
because we only got one report of the bug which has existed since 8.2, I
didn't want to risk it. Should I?
I
Hi,
Currently pg_start_backup() accesses the shared ControlFile
by using ControlFileLock with LW_EXCLUSIVE lock mode. But
since that access is read-only operation, LW_SHARED should
be chosen instead of LW_EXCLUSIVE.
The attached patch changes the lock mode which pg_start_backup()
uses. Is it
Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
So SPI interface should also be fixed, either from perl side, or maybe
from inside SPI ?
SPI has every right to assume that data it's given is already in the
database encoding.
Yeah, looks
Fujii Masao masao.fu...@gmail.com wrote:
Currently pg_start_backup() accesses the shared ControlFile
by using ControlFileLock with LW_EXCLUSIVE lock mode. But
since that access is read-only operation, LW_SHARED should
be chosen instead of LW_EXCLUSIVE.
Almost all operations of
Magnus Hagander mag...@hagander.net wrote:
The existing mechanism
works (as demonstrated by the fact that the contrib modules work on
Windows).
Did we use non-standard tools except msvc in the build framework
for core code? And what should I do for an external project?
Yes, we use
60 matches
Mail list logo
