On Wed, Jan 20, 2010 at 7:30 AM, Josh Berkus wrote:
> So, here's a must-fix item for SR for release: we need adequate docs.
> I'm happy to write these but *I* need to understand the answers first.
Thanks a lot!
> The current docs and wiki page do not explain:
>
> * How (technically) the slave li
Josh Berkus wrote:
> So, here's a must-fix item for SR for release: we need adequate docs.
> I'm happy to write these but *I* need to understand the answers first.
Many thanks!
> The current docs and wiki page do not explain:
>
> * How (technically) the slave listens for LSNs
Hmm, not sure what
On Tue, Jan 19, 2010 at 23:02, Alex Hunsaker wrote:
> On Tue, Jan 19, 2010 at 13:06, Robert Haas wrote:
>> On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker wrote:
>>> ! text attoptions[1];
>> Unfortunately this change (which is obviously correct and necessary)
>> breaks the buil
Josh Berkus wrote:
Actually, the report which MonetDB has published I believe is illegal.
If they're not running it through the TPC, they can't claim it's a
"TPCH" result.
I just resisted getting into that but now you've set me off again.
Presumably they're using the public TPC-H data and
On Tue, Jan 19, 2010 at 13:06, Robert Haas wrote:
> On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker wrote:
>> ***
>> *** 152,158 CATALOG(pg_attribute,1249) BKI_BOOTSTRAP
>> BKI_WITHOUT_OIDS BKI_ROWTYPE_OID(75) BK
>> aclitem attacl[1];
>>
>> /* Column-level o
All,
Actually, the report which MonetDB has published I believe is illegal.
If they're not running it through the TPC, they can't claim it's a
"TPCH" result.
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
Andrew Dunstan wrote:
Tim Bunce wrote:
What can I do to help the CommitFest, especially in relation to the
PL/Perl changes?
Tim.
p.s. I've sent an email to the dbi-users and dbi-announce lists
http://www.mail-archive.com/dbi-us...@perl.org/msg32649.html
in the hope of encouraging some more
Andres Freund writes:
> Is there any supported platform with sizeof(sig_atomic_t) <4 - I would doubt
> so?
Er ... what? I believe there are live platforms with sig_atomic_t = char.
If we're assuming more that's a must-fix.
regards, tom lane
--
Sent via pgsql-hackers m
Andrew Dunstan wrote:
Tim Bunce just showed me the following oddity:
andrew=# SET SESSION plperl.use_strict = on;
SET
andrew=# SHOW plperl.use_strict;
plperl.use_strict
---
on
(1 row)
andrew=# DO $$ elog(ERROR,"error") $$ language plperl;
ERROR:
Greg Stark wrote:
On Tue, Jan 19, 2010 at 2:52 PM, Greg Stark wrote:
Barring any objections shall I commit it like this?
Actually before we get there could someone who demonstrated the
speedup verify that this patch still gets that same speedup?
I think the final version of this
On Tuesday 19 January 2010 11:46:24 Simon Riggs wrote:
> On Tue, 2009-12-15 at 20:11 +0900, Hiroyuki Yamada wrote:
> > Hot Standby node can freeze when startup process calls
> > LockBufferForCleanup(). This bug can be reproduced by the following
> > procedure.
> >
> > 0. start Hot Standby, with on
Dann Corbit wrote:
See:
http://monetdb.cwi.nl/SQL/Benchmark/TPCH/
If the result is correct, then the problem queries should be added to
the regression test suite.
If the result is not correct, then perhaps they could get assistance on
proper configuration of PostgreSQL and rerun the tests.
W
On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'd like to proceed by committing an initial patch which changes the
>> "Escaping Strings for Inclusion in SQL Commands" to use a
>> with one per function (as we do in
>> surrounding functions) and consolidates it with th
On Tuesday 19 January 2010 15:57:14 Greg Stark wrote:
> On Tue, Jan 19, 2010 at 2:52 PM, Greg Stark wrote:
> > Barring any objections shall I commit it like this?
>
> Actually before we get there could someone who demonstrated the
> speedup verify that this patch still gets that same speedup?
At
Hi Greg,
On Tuesday 19 January 2010 15:52:25 Greg Stark wrote:
> On Mon, Jan 18, 2010 at 4:35 PM, Greg Stark wrote:
> > Looking at this patch for the commitfest I have a few questions.
>
> So I've touched this patch up a bit:
>
> 1) moved the posix_fadvise call to a new fd.c function
> pg_fsync
Hi Greg,
On Monday 18 January 2010 17:35:59 Greg Stark wrote:
> 2) Why does the second pass to do the fsyncs read through fromdir to
> find all the filenames. I find that odd and counterintuitive. It would
> be much more natural to just loop through the files in the new
> directory. But I suppose
On Saturday 16 January 2010 12:32:35 Simon Riggs wrote:
> On Thu, 2010-01-07 at 13:16 -0500, Robert Haas wrote:
> > On Sun, Dec 27, 2009 at 2:12 PM, Andres Freund wrote:
> > > While unlikely to cause issues two new LWLockAcquire calls use the
> > > wrong locking mode.
> > > Patch attached.
> >
>
Hi,
I know this has been discussed several times and it seems the
conclusin was it's impossible if we would like to use existing XQuery
external modules (some are by license reasons and some are by
techinical reasons).
So it seems the only way to support XQuery is, developing our own
XQuery funct
On Wed, 2010-01-13 at 00:34 -0500, Tom Lane wrote:
> Are you sufficiently excited about it to fix its memory management
> issues?
On Wed, 2010-01-13 at 09:12 -0800, Josh Berkus wrote:
> Given your interest in XML2, would you like to be come a maintainer of
> the module?
I'm wonderfully flattered b
Greg Stark writes:
> we already have statement timeout it seems the natural easy to implement
> this is with more hairy logic to calculate the timeout until the next of the
> three timeouts should fire and set sigalarm. I sympathize with whoever tries
> to work that through though, the logic is ha
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Why would they want more? It's not MySQL, and they know that.
> If we give them some very minor helpful hints for the most
> common things they try to d
On 20/01/2010 6:31 AM, Rob Wultsch wrote:
As a MySQL DBA the commands I think are most useful are:
show databases (please punt this, most MySQL dba's that I have worked
with will need to consider the difference between a db and a schema)
use database (please punt)
So perhaps for SHOW DATABASES
we already have statement timeout it seems the natural easy to implement
this is with more hairy logic to calculate the timeout until the next of the
three timeouts should fire and set sigalarm. I sympathize with whoever tries
to work that through though, the logic is hairy enough with just the two
Tim Bunce wrote:
This is the first of the patches to be split out from the former 'plperl
feature patch 1'.
Changes in this patch:
- Added utility functions: quote_literal, quote_nullable, quote_ident,
encode_bytea, decode_bytea, looks_like_number,
encode_array_literal, encode_array_c
> Devrim gave you the wrong location. It is already installed where we put
> other samples like postgresql.conf.sample, namely $SHAREDIR.
>
> Nobody has to look in the source.
>
> I don't think initdb should copy it by default, many users won't want
> such an animal at all. Maybe an initdb switc
(2010/01/20 0:19), Magnus Hagander wrote:
> 2010/1/18 KaiGai Kohei:
>> (2010/01/10 22:25), Magnus Hagander wrote:
>>> The attached patch implements RADIUS authentication (RFC2865-compatible).
>>>
>>> The main usecase for me in this is the ability to use (token based)
>>> one-time-password systems e
Josh Berkus wrote:
On 1/20/10 12:00 PM, Devrim GÜNDÜZ wrote:
On Wed, 2010-01-20 at 11:30 +1300, Josh Berkus wrote:
Also, given that recovery.conf has become a key part of our
replication, shouldn't we supply a recovery.example file which people
can rename and edit? Happy to write thi
On Wed, 2010-01-20 at 13:36 +1300, Josh Berkus wrote:
> Well, it doesn't get created in PGDATA, and the docs don't mention the
> above location that I could find.
It is installed under share/ directory for source installations. RPMs
install it under /usr/share/pgsql.
> Can we get initdb to copy
On 1/20/10 12:00 PM, Devrim GÜNDÜZ wrote:
> On Wed, 2010-01-20 at 11:30 +1300, Josh Berkus wrote:
>> Also, given that recovery.conf has become a key part of our
>> replication, shouldn't we supply a recovery.example file which people
>> can rename and edit? Happy to write this too.
>
> We ship i
On Tue, 2010-01-19 at 19:24 -0500, Tom Lane wrote:
> Jeff Davis writes:
> > I was also worried about holding multiple LWLocks at once -- is such
> > practice generally avoided in the rest of the code?
>
> It's allowed but remember that there is no deadlock detection in lwlock.c.
> You must be ver
On Tue, Jan 19, 2010 at 7:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 19, 2010 at 6:40 PM, Tom Lane wrote:
>>> A larger question, which I think has been raised before but I have not
>>> seen a satisfactory answer for, is whether the system will behave sanely
>>> at all with this
Jeff Davis writes:
> I was also worried about holding multiple LWLocks at once -- is such
> practice generally avoided in the rest of the code?
It's allowed but remember that there is no deadlock detection in lwlock.c.
You must be very certain that there is only one possible order in which
such l
On Tue, 2010-01-19 at 19:05 -0500, Tom Lane wrote:
> I guess Joachim is trying to provide a similar guarantee for the new
> implementation, but I'm not clear on why it would require locking.
> The new implementation is broadcast and ISTM it shouldn't require the
> modifying transaction to know whic
Dimitri Fontaine wrote:
Mark Kirkwood writes:
I've been using the wiki page
(http://wiki.postgresql.org/wiki/Streaming_Replication) as a guide, and I
notice that it recommends the master (and replicas) have a non-trivial
archive_command even after the backup step is completed. ISTM that afte
David Christensen writes:
> I also forgot to enclose the sample output in this version, based
> largely on Tom's wording for the USE usecase:
Please note that that was just an off-the-cuff example, not something
I thought was perfect as is ...
regards, tom lane
--
Sen
Robert Haas writes:
> On Tue, Jan 19, 2010 at 6:40 PM, Tom Lane wrote:
>> A larger question, which I think has been raised before but I have not
>> seen a satisfactory answer for, is whether the system will behave sanely
>> at all with this type of patch in place.
> I am not too sure what you th
On Jan 19, 2010, at 6:01 PM, David Christensen wrote:
On Jan 19, 2010, at 4:23 PM, Robert Haas wrote:
On Tue, Jan 19, 2010 at 5:14 PM, David E. Wheeler > wrote:
Why would they want more? It's not MySQL, and they know that. If
we give them some very minor helpful hints for the most common
Jeff Davis writes:
> How does the existing notification mechanism solve this problem? Is it
> really a problem? Why would Backend2 expect to receive the notification?
The intended way to use LISTEN/NOTIFY for status tracking is
1. LISTEN foo; (and commit the listen)
2. examine cu
On Jan 19, 2010, at 4:23 PM, Robert Haas wrote:
On Tue, Jan 19, 2010 at 5:14 PM, David E. Wheeler > wrote:
Why would they want more? It's not MySQL, and they know that. If we
give them some very minor helpful hints for the most common things
they try to do, it would be a huge benefit to them
On Tue, Jan 19, 2010 at 6:40 PM, Tom Lane wrote:
> A larger question, which I think has been raised before but I have not
> seen a satisfactory answer for, is whether the system will behave sanely
> at all with this type of patch in place. I don't really think that a
> single lock timeout applica
On Wed, 2009-12-09 at 11:43 +0100, Joachim Wieland wrote:
> Examples:
>
> Backend 1:Backend 2:
>
> transaction starts
> NOTIFY foo;
> commit starts
> transaction starts
> LISTEN foo;
> co
Boszormenyi Zoltan writes:
> [ 5-pg85-locktimeout-14-ctxdiff.patch ]
I took a quick look at this. I am not qualified to review the Win32
implementation of PGSemaphoreTimedLock, but I am afraid that both of
the other ones are nonstarters on portability grounds. sem_timedwait()
and semtimedop() d
On Wed, 2010-01-20 at 11:30 +1300, Josh Berkus wrote:
>
> Also, given that recovery.conf has become a key part of our
> replication, shouldn't we supply a recovery.example file which people
> can rename and edit? Happy to write this too.
We ship it already:
src/backend/access/transam/recovery.
Robert Haas writes:
> Although the deadline for patches for 8.5 has supposedly already passed
I guess it already got more review than some of the commit fest items
already…
Regards,
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
Mark Kirkwood writes:
> I've been using the wiki page
> (http://wiki.postgresql.org/wiki/Streaming_Replication) as a guide, and I
> notice that it recommends the master (and replicas) have a non-trivial
> archive_command even after the backup step is completed. ISTM that after the
> backup the mas
On Tue, 2010-01-19 at 21:55 +0100, Markus Wanner wrote:
> Hi,
> So, that's what I'd recommend the Mammoth developers to do as well:
> cherry-picking, sort of. Maybe that fulfills one or the other item on
> our wish-list (in one way or another)...
>
I doubt we are going to spend the time to do th
On Tue, Jan 19, 2010 at 3:14 PM, David E. Wheeler wrote:
> On Jan 19, 2010, at 1:39 PM, Tom Lane wrote:
>
>> I thought Magnus had a really good point: covering these four cases will
>> probably be enough to teach newbies to look at psql's backslash
>> commands. And once they absorb that, we're ov
Hackers,
So, here's a must-fix item for SR for release: we need adequate docs.
I'm happy to write these but *I* need to understand the answers first.
The current docs and wiki page do not explain:
* How (technically) the slave listens for LSNs
* Does the walreceiver need the archive (via archive
On Tue, Jan 19, 2010 at 5:14 PM, David E. Wheeler wrote:
> Why would they want more? It's not MySQL, and they know that. If we give them
> some very minor helpful hints for the most common things they try to do, it
> would be a huge benefit to them. I know I've badly wanted the opposite when
>
On Jan 19, 2010, at 1:39 PM, Tom Lane wrote:
> I thought Magnus had a really good point: covering these four cases will
> probably be enough to teach newbies to look at psql's backslash
> commands. And once they absorb that, we're over a big hump.
+1
On Jan 19, 2010, at 1:57 PM, Devrim GÜNDÜZ w
I've been having a look at this, one master + one replica and also one
master + 2 replicas. I gotta say this is a nice piece of functionality
(particularly the multiple replicas).
I've been using the wiki page
(http://wiki.postgresql.org/wiki/Streaming_Replication) as a guide, and
I notice th
On Jan 19, 2010, at 3:57 PM, Devrim GÜNDÜZ wrote:
On Tue, 2010-01-19 at 11:25 -0800, Jeff Davis wrote:
I like that idea. There may be a lot of MySQL people that want to use
the next postgresql release, and this would make it easier.
I disagree. If they want to use PostgreSQL, they should le
On Jan 19, 2010, at 3:39 PM, Tom Lane wrote:
David Christensen writes:
On Jan 19, 2010, at 2:58 PM, Stefan Kaltenbrunner wrote:
well those are the most common ones I guess for the current version
of the mysql commandline client - but what about future versions or
the fact that we only have p
On Tue, 2010-01-19 at 11:25 -0800, Jeff Davis wrote:
> I like that idea. There may be a lot of MySQL people that want to use
> the next postgresql release, and this would make it easier.
I disagree. If they want to use PostgreSQL, they should learn our
syntax. How can you make sure that this wil
On 1/19/2010 8:43 AM, Tom Lane wrote:
Peter Eisentraut writes:
On tis, 2010-01-19 at 01:29 -0800, Kurt Harriman wrote:
Or compiler switches could be set to disable all such warnings
globally. Warning 4514 is specific to inline functions; so
maybe it would be alright to keep it turned off glob
David Christensen writes:
> On Jan 19, 2010, at 3:12 PM, Andrew Dunstan wrote:
>> Quite apart from any considerations covered by other people, these
>> two at least could be positively misleading ... the psql commands
>> are not exact equivalents of the MySQL commands, AIUI.
> The \copy could
Robert Haas writes:
> I'd like to proceed by committing an initial patch which changes the
> "Escaping Strings for Inclusion in SQL Commands" to use a
> with one per function (as we do in
> surrounding functions) and consolidates it with the following section,
> "Escaping Binary Strings for Inc
David Christensen writes:
> On Jan 19, 2010, at 2:58 PM, Stefan Kaltenbrunner wrote:
>> well those are the most common ones I guess for the current version
>> of the mysql commandline client - but what about future versions or
>> the fact that we only have partial replacements for some of thos
David Christensen wrote:
Quite apart from any considerations covered by other people, these
two at least could be positively misleading ... the psql commands are
not exact equivalents of the MySQL commands, AIUI.
The \copy could definitely be considered a stretch; I know \c supports
more
Hi,
Jan Urbański wrote:
> sorry to butt in to the conversation, but I have spent some time
> wrapping/refining the concepts in dtester, and the results are here:
>
> http://git.wulczer.org/?p=twisted-psql.git;a=summary
That seems to cover the concurrent psql part of dtester. But I don't see
how
On Tue, Jan 19, 2010 at 3:13 PM, Tom Lane wrote:
>> It seems to me that it might be
>> sensible to do it this way:
>
>> 1. Do a locale-aware scan of the input string and count the number of
>> characters we need to escape (num_to_escape).
>> 2. If num_to_escape is 0, fast path: allocate len+3 byte
On Jan 19, 2010, at 12:58 PM, Stefan Kaltenbrunner wrote:
> well providing a hint that one should use different command will only lead to
> the path "uhm why not make it work as well"
I don't think so. People know it's a different database. They'd be thrilled
just to get the hint. I think it's
On Jan 19, 2010, at 3:12 PM, Andrew Dunstan wrote:
David Christensen wrote:
+ if (MYSQL_HELP_CHECK("use"))
+ {
+ MYSQL_HELP_OUTPUT("\\c database");
+ }
[snip]
+ else if (M
On Jan 19, 2010, at 2:58 PM, Stefan Kaltenbrunner wrote:
Tom Lane wrote:
Jeff Davis writes:
That being said, I don't have much of an opinion, so if you see a
problem, then we can forget it. After all, we would need some kind
of a
prefix anyway to avoid conflicting with actual SQL... maybe
David Christensen wrote:
+ if (MYSQL_HELP_CHECK("use"))
+ {
+ MYSQL_HELP_OUTPUT("\\c database");
+ }
[snip]
+ else if (MYSQL_HELP_CHECK("load data infile"))
+
Tom Lane wrote:
Jeff Davis writes:
That being said, I don't have much of an opinion, so if you see a
problem, then we can forget it. After all, we would need some kind of a
prefix anyway to avoid conflicting with actual SQL... maybe "\m"? And
that defeats a lot of the purpose.
Yeah, requiring
Tom Lane wrote:
> Jeff Davis writes:
> > That being said, I don't have much of an opinion, so if you see a
> > problem, then we can forget it. After all, we would need some kind of a
> > prefix anyway to avoid conflicting with actual SQL... maybe "\m"? And
> > that defeats a lot of the purpose.
>
Hi,
Greg Smith wrote:
> Takahiro Itagaki wrote:
>> The conclusion is splitting existing projects into some 'modules',
>> and getting the modules one by one into core. Voted features are here:
>> http://wiki.postgresql.org/wiki/ClusterFeatures
That's certainly been one of the outcomes, however, th
The previous discussion started from the idea that only DESCRIBE,
SHOW DATABASES/TABLES, and USE were worth worrying about. If we
were to agree that we'd go that far and no farther, the potential
conflict with SQL syntax would be pretty limited. I have little
enough experience with mysql to not
On Tue, Jan 19, 2010 at 21:44, Tom Lane wrote:
> Jeff Davis writes:
>> That being said, I don't have much of an opinion, so if you see a
>> problem, then we can forget it. After all, we would need some kind of a
>> prefix anyway to avoid conflicting with actual SQL... maybe "\m"? And
>> that defe
Jeff Davis writes:
> That being said, I don't have much of an opinion, so if you see a
> problem, then we can forget it. After all, we would need some kind of a
> prefix anyway to avoid conflicting with actual SQL... maybe "\m"? And
> that defeats a lot of the purpose.
Yeah, requiring a prefix wo
Dann Corbit wrote:
See:
http://monetdb.cwi.nl/SQL/Benchmark/TPCH/
If the result is correct, then the problem queries should be added to
the regression test suite.
If the result is not correct, then perhaps they could get assistance on
proper configuration of PostgreSQL and rerun the tests.
this
See:
http://monetdb.cwi.nl/SQL/Benchmark/TPCH/
If the result is correct, then the problem queries should be added to
the regression test suite.
If the result is not correct, then perhaps they could get assistance on
proper configuration of PostgreSQL and rerun the tests.
--
Sent via pgsql-hacke
Boszormenyi Zoltan escribió:
> May I change the interface of XactLockTableWait()
> and MultiXactIdWait()? Not the return value, only the number
> of parameters. E.g. with the relation name, like in the attached
> patch. This solves the problem of bad error messages...
> What do you think?
We alre
Jaime Casanova írta:
> 2010/1/15 Boszormenyi Zoltan :
>
>> Jaime Casanova írta:
>>
>>> 2010/1/13 Boszormenyi Zoltan :
>>>
>>>
> Your smaller patch is attached, with the above strangeness. :-)
>
>
>
>
> ok, the patch is more simpler than before and seems to
Robert Haas writes:
> Do you think we should malloc 2n+X bytes all the time, or do you want
> to scan the string once to determine how much space is needed and then
> allocate exactly that much space?
I'd vote for two scans, as I think we'll soon decide 2n doesn't cut it
anyway. One of the issue
I wrote:
> Perhaps it is as simple, though, as using the client's time
> instead of the CVS server's time -- that's one of the things I've
> seen cause problems for this sort of thing using CVS before.
I got a brief consult with a Ruby programmer here under the "if it's
less than ten minutes yo
On Tue, 2010-01-19 at 20:52 +0100, Stefan Kaltenbrunner wrote:
> Jeff Davis wrote:
> >> I'm not convinced that we should start adding syntax helpers like that
> >> to psql. For now it is an arbitrary subset of MySQL stuff, are we going
> >> to add oracle/db2/mssql/drizzle/mariadb and whatnot late
On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker wrote:
> ***
> *** 152,158 CATALOG(pg_attribute,1249) BKI_BOOTSTRAP
> BKI_WITHOUT_OIDS BKI_ROWTYPE_OID(75) BK
> aclitem attacl[1];
>
> /* Column-level options */
> ! aclitem attoptions[1];
> } For
2010/1/19 Hitoshi Harada :
> Yeah, that's my point, too. The planner has to distinguish "four" from
> sort pathkeys and to teach the executor the simple information which
> column should be used to determine frame. I was bit wrong because some
> of current executor code isn't like it, like using or
On Tue, Jan 19, 2010 at 2:38 PM, Tom Lane wrote:
> As long as it's documented it's okay ... probably ... note that
> conditionally inserting E would get us right back to the place where
> an unsafe usage might appear to work fine in light testing. Maybe
> prepend a space only if prepending E?
Th
David Christensen escreveu:
> I whipped up a quick patch for supporting some of the common mysql-based
> "meta" commands; this is different than some things which have been
> discussed in the past, in that it provides just a quick direction to the
> appropriate psql command, not an actual alternati
2010/1/15 Boszormenyi Zoltan :
> Jaime Casanova írta:
>> 2010/1/13 Boszormenyi Zoltan :
>>
Your smaller patch is attached, with the above strangeness. :-)
ok, the patch is more simpler than before and seems to be doing things right...
it passes regression tests and my own tests...
Jeff Davis wrote:
I'm not convinced that we should start adding syntax helpers like that
to psql. For now it is an arbitrary subset of MySQL stuff, are we going
to add oracle/db2/mssql/drizzle/mariadb and whatnot later on?
Also I can already see people asking "well you already know that this is
On Tue, 2010-01-19 at 11:43 -0800, Jeff Davis wrote:
> > I'm not convinced that we should start adding syntax helpers like that
> > to psql. For now it is an arbitrary subset of MySQL stuff, are we going
> > to add oracle/db2/mssql/drizzle/mariadb and whatnot later on?
> > Also I can already see
> I'm not convinced that we should start adding syntax helpers like that
> to psql. For now it is an arbitrary subset of MySQL stuff, are we going
> to add oracle/db2/mssql/drizzle/mariadb and whatnot later on?
> Also I can already see people asking "well you already know that this is
> that com
Robert Haas writes:
> On Tue, Jan 19, 2010 at 2:01 PM, Tom Lane wrote:
>> * include boundary quotes (and E too in the literal case). This would
>> imply telling people they should leave whitespace around the value in
>> the constructed query ... or should we insert leading/trailing spaces
>> to
Jeff Davis wrote:
On Tue, 2010-01-19 at 12:44 -0600, David Christensen wrote:
Hey -hackers,
I whipped up a quick patch for supporting some of the common mysql-
based "meta" commands; this is different than some things which have
been discussed in the past, in that it provides just a quick d
On Jan 19, 2010, at 11:10 AM, Tim Bunce wrote:
> What can I do to help the CommitFest, especially in relation to the
> PL/Perl changes?
Start reviewing other patches. An active/helpful patch submitter gets more love.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On Tue, 2010-01-19 at 12:44 -0600, David Christensen wrote:
> Hey -hackers,
>
> I whipped up a quick patch for supporting some of the common mysql-
> based "meta" commands; this is different than some things which have
> been discussed in the past, in that it provides just a quick direction
On Tue, Jan 19, 2010 at 2:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... I think as
>> long as we're adding a new function, we should make it behave sanely.
>> We could even take the opportunity to go back and add a saner version
>> of PQescapeStringConn.
>
> Well, it's a bit late in the dev
Tim Bunce wrote:
What can I do to help the CommitFest, especially in relation to the
PL/Perl changes?
Tim.
p.s. I've sent an email to the dbi-users and dbi-announce lists
http://www.mail-archive.com/dbi-us...@perl.org/msg32649.html
in the hope of encouraging some more people to review and tes
What can I do to help the CommitFest, especially in relation to the
PL/Perl changes?
Tim.
p.s. I've sent an email to the dbi-users and dbi-announce lists
http://www.mail-archive.com/dbi-us...@perl.org/msg32649.html
in the hope of encouraging some more people to review and test the
patches, and ho
2010/1/19 Robert Haas :
> On Tue, Jan 19, 2010 at 1:43 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Updated patch attached. I still think this is a bizarre API.
>>
>> Well, if we had it to do over I'm sure we'd have done it differently,
>> but the functions are there now and we aren't going to
Hey -hackers,
I whipped up a quick patch for supporting some of the common mysql-
based "meta" commands; this is different than some things which have
been discussed in the past, in that it provides just a quick direction
to the appropriate psql command, not an actual alternative syntax for
Robert Haas writes:
> ... I think as
> long as we're adding a new function, we should make it behave sanely.
> We could even take the opportunity to go back and add a saner version
> of PQescapeStringConn.
Well, it's a bit late in the devel cycle to be inventing from scratch,
but if we did want t
On Tue, Jan 19, 2010 at 1:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> Updated patch attached. I still think this is a bizarre API.
>
> Well, if we had it to do over I'm sure we'd have done it differently,
> but the functions are there now and we aren't going to change them ...
I agree, but
Robert Haas writes:
> Updated patch attached. I still think this is a bizarre API.
Well, if we had it to do over I'm sure we'd have done it differently,
but the functions are there now and we aren't going to change them ...
regards, tom lane
--
Sent via pgsql-hackers m
On Tue, Jan 19, 2010 at 12:54 PM, Pavel Stehule wrote:
>> I think what you're saying is that you agree with Tom's position that
>> the new escaping function should not add the necessary surrounding
>> quotes, instead leaving that to the user. Is that correct?
>
> yes
Updated patch attached. I s
"Kevin Grittner" wrote:
> I haven't looked at the fromcvs code yet to know how easy or
> hard it would be to use this logic within that package
Well, now I have looked. It's about 2,000 lines of pretty dense
Ruby code (not as many comments as one would hope, especially since
there appears to
1 - 100 of 139 matches
Mail list logo
