On Tue, May 1, 2012 at 1:10 AM, Tatsuo Ishii is...@postgresql.org wrote:
Those are the basic requirements that I am trying to address. There
are a great many important details, but the core of this is probably
what I would call logical replication, that is shipping changes to
other nodes in a
Hi hackers
After playing around with array_to_json() and row_to_json() functions a
bit it I have a question - why do we even have 2 variants *_to_json()
Collapsing array_to_json() and row_to_json() into just to_json()
As the
Hello
I have to goals for 9.3. First goal is plpgsql_check_function, second
goal is enhancing ErrorData and error management to support new
fields: COLUMN_NAME, CONSTRAINT_NAME, CONSTRAINT_SCHEMA, SCHEMA_NAME,
TABLE_NAME, ROUTINE_NAME, ROUTINE_SCHEMA, TRIGGER_NAME and
TRIGGER_SCHEMA
previous
On 1 May 2012 13:21, Pavel Stehule pavel.steh...@gmail.com wrote:
COLUMN_NAME - contains missing or inaccessible column name or empty string
CONSTRAINT_NAME - a name of constraint caused error
CONSTRAINT_SCHEMA - a name of schema where constraint is defined -
usually same as table schema in
2012/5/1 Peter Geoghegan pe...@2ndquadrant.com:
On 1 May 2012 13:21, Pavel Stehule pavel.steh...@gmail.com wrote:
COLUMN_NAME - contains missing or inaccessible column name or empty string
CONSTRAINT_NAME - a name of constraint caused error
CONSTRAINT_SCHEMA - a name of schema where constraint
On Mon, Apr 30, 2012 at 6:43 PM, Josh Berkus j...@agliodbs.com wrote:
Well, this *is* the purpose of the cluster-hackers group, to add backend
support which would make external replication systems easier to build
and more efficient. So far the only real feature to come out of that
has been
On Tue, May 1, 2012 at 7:02 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
Hi hackers
After playing around with array_to_json() and row_to_json() functions a
bit it I have a question - why do we even have 2 variants *_to_json()
Collapsing array_to_json() and row_to_json() into just to_json()
On 1 May 2012 14:01, Pavel Stehule pavel.steh...@gmail.com wrote:
What I'd also like to see, which is
something that I've agitated about in the past without much luck, is
for a new severity level, along the lines of a severe error. The
idea of this is to make a representation that the error
I think I've discovered an issue with multi-job pg_restore on a 700 GB
data file created with pg_dump. Before anyone points out that the
preferred procedure is to use the newest pg_dump to backup a database
before doing pg_restore let just say, Yes I'm aware of that advice
and unfortunately it
On Tue, May 1, 2012 at 2:09 PM, Robert Haas robertmh...@gmail.com wrote:
One thing I am a bit uncomfortable with about this whole discussion is
that it seems like a lot of the design and research is happening
off-list, with intent to report results back here later. While that
is obviously
Peter Geoghegan pe...@2ndquadrant.com writes:
Currently the following informal categories of error are bunched
together at ERROR severity:
* Integrity constraint violations
* Very serious situations, like running out of disk space
* Serious disasters that often relate to hardware failure,
We've previously discussed the possible desirability of extending
relations in larger increments, rather than one block at a time, for
performance reasons. I attempted to determine how much performance we
could possibly buy this way, and found that, as far as I can see, the
answer is, basically,
Peter Geoghegan pe...@2ndquadrant.com wrote:
Currently the following informal categories of error are bunched
together at ERROR severity:
* Integrity constraint violations
* Very serious situations, like running out of disk space
* Serious disasters that often relate to hardware failure,
On Tue, May 1, 2012 at 3:08 PM, Robert Haas robertmh...@gmail.com wrote:
We've previously discussed the possible desirability of extending
relations in larger increments, rather than one block at a time, for
performance reasons. I attempted to determine how much performance we
could possibly
On Tue, May 1, 2012 at 8:21 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
I have to goals for 9.3. First goal is plpgsql_check_function, second
goal is enhancing ErrorData and error management to support new
fields: COLUMN_NAME, CONSTRAINT_NAME, CONSTRAINT_SCHEMA, SCHEMA_NAME,
TABLE_NAME,
On Tuesday, May 01, 2012 04:08:27 PM Robert Haas wrote:
We've previously discussed the possible desirability of extending
relations in larger increments, rather than one block at a time, for
performance reasons. I attempted to determine how much performance we
could possibly buy this way, and
On Tue, May 1, 2012 at 10:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
Fair enough, but my understanding was that tests showed that the
extension lock was a bottleneck, so doing extensions in larger chunks
should reduce the time we spend waiting for a lock and thus improve
performance. So
On Tue, 2012-05-01 at 08:18 -0500, Merlin Moncure wrote:
On Tue, May 1, 2012 at 7:02 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
Hi hackers
After playing around with array_to_json() and row_to_json() functions a
bit it I have a question - why do we even have 2 variants *_to_json()
On Tue, May 1, 2012 at 10:31 AM, Andres Freund and...@anarazel.de wrote:
efficient than our current method - I'm guessing that it actually
writes the updated metadata back to disk, where write() does not (this
makes one wonder how safe it is to count on write to have the behavior
we need here
On 1 May 2012 14:55, Tom Lane t...@sss.pgh.pa.us wrote:
The last time you complained about this I suggested that looking at
SQLSTATE would resolve most of your concern. Have you pursued that
angle?
Sure, I did consider that at the time.
I think that a new severity level (equivalent to ERROR
On Tuesday, May 01, 2012 05:06:11 PM Robert Haas wrote:
On Tue, May 1, 2012 at 10:31 AM, Andres Freund and...@anarazel.de wrote:
efficient than our current method - I'm guessing that it actually
writes the updated metadata back to disk, where write() does not (this
makes one wonder how safe
On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
Hi hackers
After playing around with array_to_json() and row_to_json() functions a
bit it I have a question - why do we even have 2 variants *_to_json()
Here's the discussion where that decision was made:
2012/5/1 Robert Haas robertmh...@gmail.com:
On Tue, May 1, 2012 at 8:21 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
I have to goals for 9.3. First goal is plpgsql_check_function, second
goal is enhancing ErrorData and error management to support new
fields: COLUMN_NAME, CONSTRAINT_NAME,
On Tue, May 1, 2012 at 10:49 AM, Joey Adams joeyadams3.14...@gmail.com wrote:
On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
Hi hackers
After playing around with array_to_json() and row_to_json() functions a
bit it I have a question - why do we even have 2 variants
On Tue, 2012-05-01 at 11:49 -0400, Joey Adams wrote:
On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
Hi hackers
After playing around with array_to_json() and row_to_json() functions a
bit it I have a question - why do we even have 2 variants *_to_json()
On Tue, May 1, 2012 at 11:42 AM, Andres Freund and...@anarazel.de wrote:
There is the question whether this should be done in the background
though, so the relation extension lock is never hit in anything
time-critical...
Yeah, although I'm fuzzy on how and whether that can be made to work,
On Tue, May 1, 2012 at 9:05 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, May 1, 2012 at 10:49 AM, Joey Adams joeyadams3.14...@gmail.com
wrote:
On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing ha...@2ndquadrant.com
wrote:
Hi hackers
After playing around with array_to_json() and
On Tue, May 1, 2012 at 12:02 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I have some concerns about the performance cost of this. Now, you may
think that this is a dumb thing to be concerned about, but some
testing I've done seems to indicate that MOST of the cost of rolling
back a
On Tue, May 1, 2012 at 11:22 AM, Andrew Dunstan and...@dunslane.net wrote:
On Tue, May 1, 2012 at 9:05 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, May 1, 2012 at 10:49 AM, Joey Adams joeyadams3.14...@gmail.com
wrote:
On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing
Andrew Dunstan and...@dunslane.net writes:
Let me just point out two things. First, we are approaching a beta release.
The time for changing this is long since gone, IMNSHO.
This is our last chance to get it right, so that argument doesn't seem
to me to carry a lot of weight ...
Second, RFC
On Tue, May 1, 2012 at 12:22 PM, Andrew Dunstan and...@dunslane.net wrote:
Second, RFC 4627 is absolutely clear: a valid JSON value can only be an
object or an array, so this thing about converting arbitrary datum values to
JSON is a fantasy. If anything, we should adjust the JSON input
Brian Weaver cmdrcluel...@gmail.com writes:
I think I've discovered an issue with multi-job pg_restore on a 700 GB
data file created with pg_dump.
Just to clarify, you mean parallel restore, right? Are you using any
options beyond -j, that is any sort of selective restore?
The problem occurs
On Tue, May 1, 2012 at 10:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, May 1, 2012 at 3:08 PM, Robert Haas robertmh...@gmail.com wrote:
We've previously discussed the possible desirability of extending
relations in larger increments, rather than one block at a time, for
performance
Yeah. I also noticed in my benchmarking that sprintf() seemed to be
very slow, to the point where I wondered whether we ought to have our
own minimal version of sprintf() just for error strings.
Another idea would be to pass a flag indicating whether the context
that's going to receive the
Christopher Browne cbbro...@gmail.com writes:
Try to make sure that one of the scenarios involves there being
multiple writers.
One of the relevant cases is where there are multiple writers, where
they may wind up fighting over the last page in the table. If free
space is in that one page,
Here's the steps I'm taking
# pg_restore -l database.dump database.list
Edit the database.list file and comment out the 'PROCEDURAL LANGUAGE -
plpgsql' item. Because the dump comes from an 8.4 system without
PL/PgSQL installed by default the create language emitted during
pg_restore causes the
Doh! I missed a script that was run by cron that does a nightly
backup. That's the likely offender for the 'copy-to-stdout'
I've removed it from the nightly run. I'll see if have any better luck
with this run. Still not sure about the best way to debug the issue
though. Any pointers would be
Brian Weaver cmdrcluel...@gmail.com writes:
Doh! I missed a script that was run by cron that does a nightly
backup. That's the likely offender for the 'copy-to-stdout'
I've removed it from the nightly run. I'll see if have any better luck
with this run. Still not sure about the best way to
On 1 May 2012 17:22, Robert Haas robertmh...@gmail.com wrote:
Yeah. I also noticed in my benchmarking that sprintf() seemed to be
very slow, to the point where I wondered whether we ought to have our
own minimal version of sprintf() just for error strings.
Which sprintf()? You're probably
Tom,
The restore appears to have finished without a problem. The issue I
have is a running instance of postgres is still active in a COPY state
after the restore. The process is running full tilt, almost like it's
in a tight loop condition.
-- Brian
On Tue, May 1, 2012 at 1:44 PM, Tom Lane
On Tue, May 1, 2012 at 9:56 AM, Joey Adams joeyadams3.14...@gmail.comwrote:
On Tue, May 1, 2012 at 12:22 PM, Andrew Dunstan and...@dunslane.net
wrote:
Second, RFC 4627 is absolutely clear: a valid JSON value can only be an
object or an array, so this thing about converting arbitrary datum
Brian Weaver cmdrcluel...@gmail.com wrote:
The restore appears to have finished without a problem. The issue
I have is a running instance of postgres is still active in a COPY
state after the restore. The process is running full tilt, almost
like it's in a tight loop condition.
It's
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Brian Weaver cmdrcluel...@gmail.com wrote:
The restore appears to have finished without a problem. The issue
I have is a running instance of postgres is still active in a COPY
state after the restore. The process is running full tilt, almost
Excerpts from Tom Lane's message of mar may 01 13:19:48 -0400 2012:
Christopher Browne cbbro...@gmail.com writes:
Try to make sure that one of the scenarios involves there being
multiple writers.
One of the relevant cases is where there are multiple writers, where
they may wind up
There is this rule in src/port/Makefile:
%_srv.o: %.c
$(CC) $(CFLAGS) $(subst -DFRONTEND,, $(CPPFLAGS)) -c $ -o $@
But this rule doesn't observe dependency tracking, so if you change a
header file, these files won't get build as necessary. This is the only
case in the source tree where
On Tue, May 1, 2012 at 3:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
The system is supposed to be designed to avoid that; we try to hand out
pages with free space to different backends. One of the advantages of
the current page-at-a-time setup is that when there is *no* free space
On Tue, May 01, 2012 at 02:19:16PM +0100, Peter Geoghegan wrote:
Currently the following informal categories of error are bunched
together at ERROR severity:
* Integrity constraint violations
* Very serious situations, like running out of disk space
* Serious disasters that often relate to
* Robert Haas (robertmh...@gmail.com) wrote:
I think the first thing we need here is a good test case, so we're
clear on what we're trying to solve. I was just hoping to make file
extension *faster* and what you and Simon are talking about is making
it scale better in the face of heavy
Excerpts from Peter Eisentraut's message of mar may 01 15:30:25 -0400 2012:
Instead, I thought this could easily be fixed by writing this:
%_srv.o: %.c %.o
$(CC) $(CFLAGS) $(subst -DFRONTEND,, $(CPPFLAGS)) -c $ -o $@
A bit hacky, but should get quite robust results.
So basically
On Wed, Apr 18, 2012 at 05:08:06PM +0300, Peter Eisentraut wrote:
On tis, 2012-04-17 at 10:52 -0400, Jay Levitt wrote:
Maybe I'm confused - Magnus et al, are we talking spammy issues/issue
comments/etc, or are we talking more about exposed email addresses?
My github.com account currently
Excerpts from Noah Misch's message of mar may 01 15:36:22 -0400 2012:
On Tue, May 01, 2012 at 02:19:16PM +0100, Peter Geoghegan wrote:
The first category of error is something that the DBA will often see
very frequently. The latter 3 are situations which I'd like to be
woken up in the
On 4/17/12 7:19 AM, Greg Stark wrote:
On Mon, Apr 16, 2012 at 10:42 PM, Peter Geogheganpe...@2ndquadrant.com wrote:
All but 4 regression tests pass, but they don't really count
as failures, since they're down to an assumption in the tests that the
order certain tuples appear should be
Noah Misch n...@leadboat.com writes:
I agree that some means to mechanically distinguish these cases would
constitute a significant boon for admin monitoring. Note, however, that the
same split appears at other severity levels:
FATAL, routine: terminating connection due to conflict with
On 4/25/12 6:16 AM, Simon Riggs wrote:
The way standard-like temporary tables work is exactly why I assume
Noah proposes to implement them: because they work nicely with HS.
Well, following a standard that no other major DBMS has followed is
not great, especially if it leads to a non-useful
On 1 May 2012 20:36, Noah Misch n...@leadboat.com wrote:
I agree that some means to mechanically distinguish these cases would
constitute a significant boon for admin monitoring. Note, however, that the
same split appears at other severity levels:
FATAL, routine: terminating connection due
Peter Geoghegan pe...@2ndquadrant.com writes:
Maybe no one is convinced by any of this, but the fact is that the
SQLSTATE argument falls down when one considers that we aren't using
it in many cases of errors that clearly are severe.
The reason that argument isn't convincing is that we *are*
On Tue, 2012-05-01 at 12:54 -0400, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Let me just point out two things. First, we are approaching a beta release.
The time for changing this is long since gone, IMNSHO.
This is our last chance to get it right, so that argument doesn't
On 4/25/12 6:15 PM, Jaime Casanova wrote:
On Wed, Apr 25, 2012 at 5:46 PM, Merlin Moncuremmonc...@gmail.com wrote:
I don't know how GTT play inside the Oracle stack such that they
aren't super popular, but if they work in the standby they will
quickly become a killer feature. IMNSHO
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Peter Eisentraut's message of mar may 01 15:30:25 -0400 2012:
Instead, I thought this could easily be fixed by writing this:
%_srv.o: %.c %.o
$(CC) $(CFLAGS) $(subst -DFRONTEND,, $(CPPFLAGS)) -c $ -o $@
A bit hacky, but
Excerpts from Tom Lane's message of mar may 01 16:25:07 -0400 2012:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Peter Eisentraut's message of mar may 01 15:30:25 -0400 2012:
Instead, I thought this could easily be fixed by writing this:
%_srv.o: %.c %.o
$(CC)
On 1 May 2012 21:14, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan pe...@2ndquadrant.com writes:
Maybe no one is convinced by any of this, but the fact is that the
SQLSTATE argument falls down when one considers that we aren't using
it in many cases of errors that clearly are severe.
On Tue, Apr 24, 2012 at 09:29:39PM +0300, Peter Eisentraut wrote:
I propose that we remove support for the following OS ports from our
source tree. They are totally dead, definitely don't work, and/or
probably no one remembers what they even were. The code just bit rots
and is in the way of
On Tue, May 1, 2012 at 3:48 PM, Stephen Frost sfr...@snowman.net wrote:
Try loading the TIGER 2011 data into a single table, where you load each
county (or perhaps state) in a separate, parallel, process. That's what
I was doing when I hit this lock full-force and bitched about it on this
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of mar may 01 16:25:07 -0400 2012:
Are there, or might there be in the future, any port files that only
exist in server flavor and not client-side flavor?
Now, there is someone with a patch that duplicates some
On Tue, May 1, 2012 at 10:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Peter Eisentraut's message of mar may 01 15:30:25 -0400 2012:
Instead, I thought this could easily be fixed by writing this:
%_srv.o: %.c %.o
$(CC)
On Tue, 2012-05-01 at 11:11 -0700, Andrew Dunstan wrote:
On Tue, May 1, 2012 at 9:56 AM, Joey Adams
joeyadams3.14...@gmail.com wrote:
...
No, the RFC says (emphasis mine):
A JSON *text* is a serialized object or array.
If we let
Magnus Hagander mag...@hagander.net writes:
On Tue, May 1, 2012 at 10:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Are there, or might there be in the future, any port files that only
exist in server flavor and not client-side flavor?
Isn't that what backend/port/* is for?
Ah, good point.
Peter Geoghegan pe...@2ndquadrant.com wrote:
The argument could be made that what I've characterised as severe
(which is, as I've said, not entirely clear-cut) could be deduced
from SQLSTATE if we were to formalise the can't happen errors are
only allowed to use elog() convention into a hard
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, May 1, 2012 at 3:48 PM, Stephen Frost sfr...@snowman.net wrote:
I'd be happy to help construct that case, as well as test any changes in
this area which might help address it (on a 10G SSD-backed SAN..).
Hmm, can you ship me one
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Peter Geoghegan
Sent: Tuesday, May 01, 2012 4:37 PM
To: Tom Lane
Cc: Pavel Stehule; PostgreSQL Hackers
Subject: Re: [HACKERS] proposal: additional error fields
On
On Fri, Apr 27, 2012 at 3:05 PM, Noah Misch n...@leadboat.com wrote:
On Thu, Apr 26, 2012 at 09:25:25PM +0300, Peter Eisentraut wrote:
On m??n, 2012-04-23 at 12:30 -0400, Noah Misch wrote:
I've been enjoying \x auto in .psqlrc, but I noticed the row count footer
missing when it chooses
On Tue, 2012-05-01 at 09:22 -0700, Andrew Dunstan wrote:
On Tue, May 1, 2012 at 9:05 AM, Merlin Moncure mmonc...@gmail.com
wrote:
On Tue, May 1, 2012 at 10:49 AM, Joey Adams
joeyadams3.14...@gmail.com wrote:
On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing
Hi Erik
On Sun, Apr 29, 2012 at 4:12 PM, Erik Rijkers e...@xs4all.nl wrote:
Perhaps I'm too early with these tests, but FWIW I reran my earlier test
program against three
instances. (the patches compiled fine, and make check was without
problem).
-- 3 instances:
HEAD
On Mon, Apr 30, 2012 at 10:07 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Apr 29, 2012 at 8:12 AM, Erik Rijkers e...@xs4all.nl wrote:
Perhaps I'm too early with these tests, but FWIW I reran my earlier test
program against three
instances. (the patches compiled fine, and make
On Tue, May 1, 2012 at 1:48 AM, Kevin Grittner
kevin.gritt...@wicourts.govwrote:
My biggest complaint is related to setting the threshold for the %
operator. It seems to me that there should be a GUC to control the
default, and that there should be a way to set the threshold for
each %
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Hannu Krosing
Sent: Tuesday, May 01, 2012 5:29 PM
The reason I am whining now is that with minor adjustments in
implementation it could all be made much more
On 1 May 2012 22:09, Kevin Grittner kevin.gritt...@wicourts.gov wrote:
That doesn't seem necessary or desirable. The thing to do is to
somewhere define a list of what is severe. It seems likely that
different shops may have different opinions on what constitutes a
severe problem, or may have
Andrew Dunstan and...@dunslane.net writes:
On Tue, May 1, 2012 at 9:56 AM, Joey Adams joeyadams3.14...@gmail.comwrote:
No, the RFC says (emphasis mine):
A JSON *text* is a serialized object or array.
If we let the JSON type correspond to a *value* instead, this
restriction does not apply,
Peter Geoghegan pe...@2ndquadrant.com writes:
There is another advantage to doing this within the core system that I
have not touched upon, which is that in this way we can expose another
useful GUC to reduce log noise, beyond log_min_messages.
Yeah, that one is actually a pretty compelling
On Tue, May 1, 2012 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I continue to maintain that the SQLSTATE is a much better basis for
solving this problem. Its categories are already pretty close to
what Peter needs: basically, IIUC, he wants to know about classes
53, 58, maybe F0, and XX.
Robert Haas robertmh...@gmail.com writes:
On Tue, May 1, 2012 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I continue to maintain that the SQLSTATE is a much better basis for
solving this problem. Its categories are already pretty close to
what Peter needs: basically, IIUC, he wants to know
On May 1, 2012, at 20:05, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 1, 2012 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I continue to maintain that the SQLSTATE is a much better basis for
solving this problem. Its categories are already pretty close to
what Peter needs:
On Tue, 2012-05-01 at 18:35 -0400, David Johnston wrote:
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Hannu Krosing
Sent: Tuesday, May 01, 2012 5:29 PM
The reason I am whining now is that with minor
Quite apart from the practical difficulties that we have with Flex
(the fact that the authors are non-responsive and possibly retired,
that annoying compiler warning, and the fact that we are forced to
maintain our own Windows binaries of 2.5.35), it has some notable
disadvantages. I am aware that
On 2 May 2012 01:13, Tom Lane t...@sss.pgh.pa.us wrote:
I don't deny that we probably need to reclassify a few error cases, and
fix some elogs that should be ereports, before this approach would be
really workable. My point is that it's *close*, whereas let's invent
some new error severities
On May 1, 2012, at 20:41, Hannu Krosing ha...@2ndquadrant.com wrote:
Most people don't work in strongly-typed environment, and thus would
work around such restriction if they need a simple JSON value at the
other end of the interchange.
My personal take it is have it fail since any
Peter Geoghegan pe...@2ndquadrant.com writes:
... I have heard people complain about Postgres
parser overhead for pgbench -S style use-cases where it is
unreasonably high, and I've heard them do so more than once.
I was under the impression that those cycles were mostly in bison not
flex...
Peter Geoghegan pe...@2ndquadrant.com writes:
Quite apart from the practical difficulties that we have with Flex
(the fact that the authors are non-responsive and possibly retired,
btw, as far as that goes, a look into their sourceforge SCM shows
evidence of continued activity. I dunno why
On Tue, May 1, 2012 at 8:53 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
I'm certainly not suggesting that this isn't something that, in order
to be adopted, will have to be carefully considered from many angles,
of which the performance of the resulting lexer is only one, but at
the same
Robert Haas robertmh...@gmail.com writes:
One fairly major obstacle to using quex for anything is that it
doesn't appear to be packaged on either Fedora or Ubuntu (I tried
apt-cache search quex on my Ubuntu laptop, and yum install quex on an
F16 machine). 'port install quex' on my MacOS X
2012/5/2 Robert Haas robertmh...@gmail.com:
On Tue, May 1, 2012 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I continue to maintain that the SQLSTATE is a much better basis for
solving this problem. Its categories are already pretty close to
what Peter needs: basically, IIUC, he wants to
Hi All,
Please forward this mail to the correct mailing list if this is not a right
place,
Please send me the link or white papers from where i can get information
like.
1. Feature comparison in between PostgreSQL 9.x with MySql or MariaDB
2. if possible specially with DBaaS
3. Feature
92 matches
Mail list logo
