Hi,
Robert Haas robertmh...@gmail.com writes:
I don't really believe that JSON is only one use case. XML and JSON
are in a class of their own; there's nothing else out there that is
really comparable.
You might want to hear about the UBF specs from Joe Armstrong, let me
quote its page about
forward patch to pg_hackers
There is fixed patch. Please, Jaime, can you look on it?
Thank You
Pavel
2009/7/30 Tom Lane t...@sss.pgh.pa.us:
Jaime Casanova jcasa...@systemguards.com.ec writes:
On Mon, Jul 20, 2009 at 10:09 AM, Alvaro
Getting rid of the check on natts was ungood ... it needs
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
David Fetter wrote:
On Mon, Aug 03, 2009 at 11:18:55PM -0400, Stephen Frost wrote:
Just generally, access control is a great way to describe what's
actually happening here. That people conflate access control with
security has resulted in a
Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 24, 2009 at 4:24 PM, Peter Eisentrautpete...@gmx.net wrote:
On Friday 26 June 2009 12:07:24 Tsutomu Yamada wrote:
Included is a conceptual patch to use intptr_t. Comments are welcome.
After closer inspection, not having a win64 box
Hi,
It seems there's no way to do %-expansion in plpgsql when one is using
RAISE USING:
alvherre=# create or replace function f () returns void language plpgsql as $$
begin
raise using message = 'hello %' || 'world';
return;
end;
$$;
CREATE FUNCTION
alvherre=# select f();
ERROR: hello
Stephen Frost sfr...@snowman.net writes:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
My concern is access_control_ is a bit long for prefixes,
but ac_ is too short to represent what it is doing.
pg_ac_? Still shorter than 'security_', uses the pg_ prefix, which we
use in a number of other
Greg Stark gsst...@mit.edu writes:
On Tue, Aug 4, 2009 at 5:04 AM, Tom Lanet...@postgresql.org wrote:
Cause pg_proc.probin to be declared as text, not bytea.
Doesn't this relate to the earlier discussion of whether to re-encode
filenames and paths?
What's going to happen if I have filenames
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Alvaro Herrera wrote:
Joe Conway escribió:
OK, how's this look?
Hmm, is it possible to use OUT parameters in the function instead of
declaring a new type for the result?
Sure, I guess I ought to use the latest-and-greatest. Any other
Alvaro Herrera alvhe...@commandprompt.com writes:
It seems there's no way to do %-expansion in plpgsql when one is using
RAISE USING:
That's intentional. Just use string concatenation if you need a
run-time-variable message.
regards, tom lane
--
Sent via
Hello
2009/8/4 Alvaro Herrera alvhe...@commandprompt.com:
Hi,
It seems there's no way to do %-expansion in plpgsql when one is using
RAISE USING:
alvherre=# create or replace function f () returns void language plpgsql as $$
begin
raise using message = 'hello %' || 'world';
return;
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
My concern is access_control_ is a bit long for prefixes,
but ac_ is too short to represent what it is doing.
pg_ac_? Still shorter than 'security_', uses the
On Monday 03 August 2009 23:08:51 Josh Berkus wrote:
There's another question for alpha releases: are we going to build docs?
Yes, absolutely. I'm working on making the documentation build part of the
tarball build procedure.
Either for www.postgresql.org, or for PGDATA/docs?
The web team
On Monday 03 August 2009 23:13:27 Alvaro Herrera wrote:
Josh Berkus wrote:
I think we need some kind of docs up, otherwise we'll get little
actual testing. As previously discussed, building the docs yourself
from pure source involves several complicated dependancies which
aren't
Pavel Stehule pavel.steh...@gmail.com writes:
I agree, so information about patch would be store in text field. But
I am not sure, if your fix isn't too simply. I haven't plan to compile
plpgsql to C or to binary code. But could be interesting link postgres
with some virtual machine like
On Tuesday 04 August 2009 14:03:34 Tsutomu Yamada wrote:
Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 24, 2009 at 4:24 PM, Peter Eisentrautpete...@gmx.net wrote:
On Friday 26 June 2009 12:07:24 Tsutomu Yamada wrote:
Included is a conceptual patch to use intptr_t. Comments are
On Monday 03 August 2009 22:11:08 Tom Lane wrote:
I'm starting to look at this patch. I observe that it's setting the
default output format to HEX. If changing the default behavior was
agreed to, or even discussed, I do not remember where. Shouldn't the
default stay the same?
I did pose
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
It seems there's no way to do %-expansion in plpgsql when one is using
RAISE USING:
That's intentional. Just use string concatenation if you need a
run-time-variable message.
Yes, I can do that, but it's really ugly and
On Tue, Aug 4, 2009 at 16:10, Peter Eisentrautpete...@gmx.net wrote:
On Tuesday 04 August 2009 14:03:34 Tsutomu Yamada wrote:
Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 24, 2009 at 4:24 PM, Peter Eisentrautpete...@gmx.net wrote:
On Friday 26 June 2009 12:07:24 Tsutomu Yamada
Joe Conway m...@joeconway.com writes:
Sure, I guess I ought to use the latest-and-greatest. Any other comments
before I commit?
That be_pid/be_pid hack in the regression test is pretty ugly, and
doesn't test anything very useful anyway seeing that it's integer
division. Could you do something
On Monday 03 August 2009 22:52:55 David Fetter wrote:
On Mon, Aug 03, 2009 at 09:22:52PM +0300, Peter Eisentraut wrote:
On Monday 03 August 2009 21:07:00 David Fetter wrote:
We require that people supply docs with their changes, and it is
totally unreasonable to let them send in catalog
On Tue, Aug 4, 2009 at 16:06, Peter Eisentrautpete...@gmx.net wrote:
On Monday 03 August 2009 23:08:51 Josh Berkus wrote:
The web team has to figure out whether putting the docs on the web site is
worthwhile. We already have the developer docs that are rebuild on every
check-in.
As long as
Peter Eisentraut pete...@gmx.net writes:
On Monday 03 August 2009 22:11:08 Tom Lane wrote:
I'm starting to look at this patch. I observe that it's setting the
default output format to HEX. If changing the default behavior was
agreed to, or even discussed, I do not remember where. Shouldn't
On Tue, Aug 4, 2009 at 10:28 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On Monday 03 August 2009 22:11:08 Tom Lane wrote:
I'm starting to look at this patch. I observe that it's setting the
default output format to HEX. If changing the default behavior was
On Tue, Aug 4, 2009 at 16:31, Robert Haasrobertmh...@gmail.com wrote:
On Tue, Aug 4, 2009 at 10:28 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On Monday 03 August 2009 22:11:08 Tom Lane wrote:
I'm starting to look at this patch. I observe that it's setting
On Mon, Aug 03, 2009 at 10:03:47AM -0500, Kevin Grittner wrote:
That's about 0.52% slower with the patch. Because there was over 10%
variation in the numbers with the patch, I tried leaving out the four
highest outliers on both, in case it was the result of some other
activity on the system
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 4, 2009 at 10:28 AM, Tom Lanet...@sss.pgh.pa.us wrote:
If this seems reasonable, I can make a note of the point in the commit
message, so that we won't forget when the time comes.
Or, what we could do is start an open items for 8.5 list
On Tue, Aug 4, 2009 at 2:46 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I'll point out though that having probin declared bytea would surely
be antithetical to any attempt to treat shlib filenames in an
encoding-aware fashion. Declaring it that way implies that it is
*not* storing a character
Pavel Stehule escribió:
I agree, so information about patch would be store in text field. But
I am not sure, if your fix isn't too simply. I haven't plan to compile
plpgsql to C or to binary code. But could be interesting link postgres
with some virtual machine like parrot or lua vm, and
Sam Mason s...@samason.me.uk writes:
t = 0.54 ((avg1 - avg2) / (stddev * sqrt(2/samples)))
We then have to choose how certain we want to be that they're actually
different, 90% is a reasonably easy level to hit (i.e. one part in ten,
with 95% being more commonly quoted). For 20
Peter Eisentraut pete...@gmx.net writes:
On Monday 03 August 2009 23:13:27 Alvaro Herrera wrote:
Are we going to ship ChangeLog files or some such, giving that we're not
going to have release notes?
There will still be release notes. They might not be as polished as the
final
ones, but
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Monday 03 August 2009 23:13:27 Alvaro Herrera wrote:
Are we going to ship ChangeLog files or some such, giving that we're not
going to have release notes?
There will still be release notes. They might not be as polished as the
Magnus Hagander mag...@hagander.net writes:
On Tue, Aug 4, 2009 at 16:10, Peter Eisentrautpete...@gmx.net wrote:
Well, there is nothing outright wrong with this patch, but without any
measurable effect, it is too early to commit it. At least I would like to
see
the Datum typedef to be
2009/8/4 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I agree, so information about patch would be store in text field. But
I am not sure, if your fix isn't too simply. I haven't plan to compile
plpgsql to C or to binary code. But could be interesting link
Greg Stark wrote:
On Tue, Aug 4, 2009 at 2:46 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I'll point out though that having probin declared bytea would surely
be antithetical to any attempt to treat shlib filenames in an
encoding-aware fashion. Declaring it that way implies that it is
*not*
On Tue, Aug 04, 2009 at 10:45:52AM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
t = 0.54 ((avg1 - avg2) / (stddev * sqrt(2/samples)))
We then have to choose how certain we want to be that they're actually
different, 90% is a reasonably easy level to hit (i.e. one
On Tuesday 04 August 2009 17:48:12 Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Monday 03 August 2009 23:13:27 Alvaro Herrera wrote:
Are we going to ship ChangeLog files or some such, giving that we're not
going to have release notes?
There will still be release notes.
On Tuesday 04 August 2009 17:56:41 Tom Lane wrote:
The other thing that I would say is a non-negotiable minimum requirement
is that the patch include the necessary configure pushups so it does not
break machines without uintptr_t.
There is AC_TYPE_UINTPTR_T, so that should be easy.
--
Sent
On Tue, Aug 4, 2009 at 10:48 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On Monday 03 August 2009 23:13:27 Alvaro Herrera wrote:
Are we going to ship ChangeLog files or some such, giving that we're not
going to have release notes?
There will still be
Andrew Dunstan and...@dunslane.net writes:
Is this any different from the path in COPY foo to '/path/to/file'?
I suspect the probin stuff is a solution in search of a problem.
Well, the previous probin behavior is demonstrably broken. Make a shlib
with backslash or non-ASCII in the name,
Peter Eisentraut pete...@gmx.net writes:
On Tuesday 04 August 2009 17:56:41 Tom Lane wrote:
The other thing that I would say is a non-negotiable minimum requirement
is that the patch include the necessary configure pushups so it does not
break machines without uintptr_t.
There is
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 4, 2009 at 10:48 AM, Tom Lanet...@sss.pgh.pa.us wrote:
That would be great, but who's going to do them?
I think the question is who are you going to allow to do them?.
You misread that entirely. What I was pointing out was that we didn't
On Tue, Aug 4, 2009 at 11:44 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 4, 2009 at 10:48 AM, Tom Lanet...@sss.pgh.pa.us wrote:
That would be great, but who's going to do them?
I think the question is who are you going to allow to do them?.
Robert Haas robertmh...@gmail.com writes:
I'm willing to help if these are 8.5 release notes in process. I'm
not willing to help if they are alpha release notes that will be
thrown away afterwards. Which is it?
That depends largely on what they look like when we get to beta,
I imagine. Are
--On Montag, August 03, 2009 23:43:08 +0200 Bernd Helmle
maili...@oopsware.de wrote:
Status Report: I will finish documentation and review tomorrow and will
mark this patch for committer review.
Here's my latest reviewed version of Pavel's patch with adjusted
documentation per latest
--On Dienstag, August 04, 2009 10:28:48 -0400 Tom Lane t...@sss.pgh.pa.us
wrote:
While I've been poking at the pg_dump issues, it's occurred to me that
changing the default would be a great forcing function for finding out
any lurking problems.
+1
--
Thanks
Bernd
--
Bernd Helmle maili...@oopsware.de writes:
--On Samstag, Juli 11, 2009 13:40:44 +0300 Peter Eisentraut
pete...@gmx.net wrote:
OK, here is an updated patch. It has the setting as enum, completed
documentation, and libpq support. I'll add it to the commit fest in the
hope that someone else
On Tue, Aug 4, 2009 at 12:01 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I'm willing to help if these are 8.5 release notes in process. I'm
not willing to help if they are alpha release notes that will be
thrown away afterwards. Which is it?
That depends
I wrote:
While I've been poking at the pg_dump issues, it's occurred to me that
changing the default would be a great forcing function for finding out
any lurking problems. What I'm inclined to do now is to commit it
*with* the change of default, and let it be that way at least for a
few
Hi,
I think the case for machine-readable error fields is well made and
doesn't need any further push.
So, what do we need to make it happen? Here's my proposal.
First we need several new error message fields: table name, function
name, constraint name, and so on. One possible way to go about
On Sat, Aug 1, 2009 at 20:30, Kevin Fieldkevinjamesfi...@gmail.com
wrote:
The event viewer says:
The description for Event ID ( 0 ) in Source ( PostgreSQL )
cannot
be
found. The local computer may not have the necessary registry
information or message DLL files to display
On Tuesday 04 August 2009 18:52:06 Robert Haas wrote:
I'm willing to help if these are 8.5 release notes in process. I'm
not willing to help if they are alpha release notes that will be
thrown away afterwards. Which is it?
I was working on the latter assumption.
I have some reservations
* Stephen Frost (sfr...@snowman.net) wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Jul 22, 2009 at 11:26 PM, Petr Jelinekpjmo...@pjmodos.net wrote:
The docs are not complete but that's up to Stephen, otherwise the patch
should be finished. But I am not the reviewer :)
I have some reservations about the former approach. It would basically commit
us right now to having a consistent set of volunteers available every two
months within specific 1-2 day spans. Which is the sort of thing I wanted to
avoid. But if we have that commitment, then go for it.
Can we
On Tue, Aug 04, 2009 at 01:28:00PM -0400, Stephen Frost wrote:
Thanks to Joshua, there weren't really many changes I found for the
docs. Here they are anyway:
Yay, I was useful! :)
How about:
Replaces current privileges with the default privileges, as set using
xref
Magnus,
I don't think we should keep an archive of old alphas though -
that's going to leave us with insane amounts of documentation sets.
But we could have a /docs/alpha/ which would hold the latest released
alpha.
Yes, that's perfect.
For that matter, for the release notes, I wasn't
I mentioned in
http://archives.postgresql.org/message-id/21837.1248215...@sss.pgh.pa.us
that pg_dump has a bug in its handling of large objects, which is
directly related to the fact that it's still using the deprecated
function PQescapeBytea. The reason PQescapeBytea is deprecated is
that it has
On Tue, Aug 4, 2009 at 1:19 PM, Peter Eisentrautpete...@gmx.net wrote:
On Tuesday 04 August 2009 18:52:06 Robert Haas wrote:
I'm willing to help if these are 8.5 release notes in process. I'm
not willing to help if they are alpha release notes that will be
thrown away afterwards. Which is
Alvaro Herrera alvhe...@commandprompt.com writes:
First we need several new error message fields: table name, function
name, constraint name, and so on.
It would also help to have clear definitions of what these *mean*, which
is entirely unclear from your comments --- in particular, the
2009/8/4 Bernd Helmle maili...@oopsware.de:
--On Montag, August 03, 2009 23:43:08 +0200 Bernd Helmle
maili...@oopsware.de wrote:
Status Report: I will finish documentation and review tomorrow and will
mark this patch for committer review.
Here's my latest reviewed version of Pavel's patch
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
First we need several new error message fields: table name, function
name, constraint name, and so on.
It would also help to have clear definitions of what these *mean*, which
is entirely unclear from your comments --- in
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
Lastly, I'm not as sure as you are that the case for these is well made.
In exactly what cases would client code be able to do something useful
with them? Your proposal involves a pretty huge amount of work if we
are to carry
2009/8/4 Tom Lane t...@sss.pgh.pa.us:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
Lastly, I'm not as sure as you are that the case for these is well made.
In exactly what cases would client code be able to do something useful
with them? Your proposal involves a pretty
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
It would also help to have clear definitions of what these *mean*, which
is entirely unclear from your comments --- in particular, the reference
to errcontext callbacks confuses the heck out of me. I would have
thought that
On Tue, 2009-08-04 at 13:35 -0400, Tom Lane wrote:
I speculated about fixing that by inventing a PQescapeByteaHex
function, but that was pure brain fade :-(. The hex format for
bytea still requires one backslash in the value, so you still have
to know standard_conforming_strings to get it
On Tue, Aug 4, 2009 at 4:05 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
Lastly, I'm not as sure as you are that the case for these is well made.
In exactly what cases would client code be able to do something useful
with them? Your
Jeff Davis pg...@j-davis.com writes:
On a related topic: right now it's impossible to safely escape (using
libpq alone) bytea data for use as a text-format argument to a
parameterized query. This is because PQescapeBytea returns a string that
is both escaped for bytea and escaped for inclusion
Tom Lane wrote:
If there are situations where this info is missing from the
human-readable message, then sure, let's look into fixing that.
But the use-case for automatic interpretation of the message
is just a whole lot smaller than would justify the work.
To take just one point, I rather
Hi all,
Does someone has some material which explain how the executor works?
I'm looking for the internal processing of a query in the _executor_.
Thanks for help
Edson Ramiro
I found these docs to very helpful for understand how the backend works,
but for the executor specifically, I think following the code is best.
http://anoncvs.postgresql.org/cvsweb.cgi/~checkout~/pgsql/src/tools/backend/index.html
--
--Dan
On Tue, Aug 04, 2009 at 05:35:04PM -0300, Edson Ramiro
Edson Ramiro erlfi...@gmail.com writes:
Does someone has some material which explain how the executor works?
Did you read
http://developer.postgresql.org/pgdocs/postgres/overview.html
and src/backend/executor/README?
Once you get through those, reading the source code is the next step.
It seems that last contrib crypto changes broke buildfarm. You can see
problem e.g. here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=emperor_mothdt=2009-08-04%2020:06:01
I don't have time to look on it now. But it should be reproducible
everywhere.
Zdenek
--
Sent via
On Tuesday 04 August 2009 23:19:24 Tom Lane wrote:
Also, you completely dodged the question of defining what the fields
really mean, which would be 100% essential to doing anything automatic
with the results. If errtable sometimes means a table that doesn't
exist, and sometimes means a table
Robert Haas robertmh...@gmail.com writes:
Right now, I do this like this:
if ($err =~ /name_of_first_foreign_key/) {
$r-error_exit('First error message.')
}
elsif ($err =~ /name_of_second_foreign_key/) {
...
I've always found that a bit icky because it relies (for example) on
their not
Tom Lane escribió:
However, I wonder whether we could turn this around. Instead of an
open-ended project to add an ill-defined collection of fields to an
ill-defined collection of error cases, maybe we could identify a
very short list of cases where it's known to be useful to pull a
On Tue, Aug 4, 2009 at 5:23 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Right now, I do this like this:
if ($err =~ /name_of_first_foreign_key/) {
$r-error_exit('First error message.')
}
elsif ($err =~ /name_of_second_foreign_key/) {
...
I've always
Hmm, well, I skipped the rationale because it has been requested before.
For example, we need to give constraint names so that applications can
tell which unique key is being violated. We need table names on which
they are being violated. We need column names for datatype mismatches,
and
Zdenek Kotala wrote:
It seems that last contrib crypto changes broke buildfarm. You can see
problem e.g. here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=emperor_mothdt=2009-08-04%2020:06:01
I don't have time to look on it now. But it should be reproducible
everywhere.
It's not
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
If that's what we're trying to solve, I don't think that adding some
kind of proprietary shorthand coding is a good idea. If we're do to
this at all, it should be a connection-based GUC option, and use some
standard formal like XML
--On 4. August 2009 20:22:05 +0200 Pavel Stehule pavel.steh...@gmail.com
wrote:
Named notation has different algorithm for function detection then
positional notation. There are not exist variadic parameters (because
these parameters hasn't individual names). So only packed variadic
Josh Berkus j...@agliodbs.com writes:
If that's what we're trying to solve, I don't think that adding some
kind of proprietary shorthand coding is a good idea. If we're do to
this at all, it should be a connection-based GUC option, and use some
standard formal like XML fragments.
Huh? What
Alvaro Herrera alvhe...@commandprompt.com writes:
It's not crypto changes that's the problem -- it's bytea now
being output in hex form (encrypt and decrypt both return bytea):
I was insufficiently careful about checking the non-core regression
tests :-(. Mea culpa.
Tom Lane t...@sss.pgh.pa.us wrote:
A minimum requirement for such a thing, in my opinion, is that
*every* occurrence of one of the targeted SQLSTATE codes should be
able to produce the same auxiliary fields with the same meanings.
If you can't define it that way, then you haven't actually
On Sat, Aug 1, 2009 at 12:35 AM, Alvaro
Herreraalvhe...@commandprompt.com wrote:
Teodor Sigaev wrote:
As for the contrib module, I think it could use a lot more function
header comments! Also, it would be great if it could be used separately
from tsearch, i.e. that it provided a function
Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
My concern is access_control_ is a bit long for prefixes,
but ac_ is too short to represent what it is doing.
pg_ac_? Still shorter than
On Tue, Aug 4, 2009 at 11:28 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Huh? What he was talking about is providing additional error fields,
which would presumably be made available via PQresultErrorField in
libpq, or its kin in other interfaces, and would be totally invisible to
any client that
On Tue, Aug 04, 2009 at 10:06:37PM -, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
If that's what we're trying to solve, I don't think that adding
some kind of proprietary shorthand coding is a good idea. If
we're do to this at all, it should be
Greg Stark wrote:
So an alternate proposal is to add a field in the error message which
contains the untranslated string. That would let applications always
look at the untranslated string for parsing and always use the
translated string for user displays.
That's an interesting idea, but you
David Fetter wrote:
On Tue, Aug 04, 2009 at 10:06:37PM -, Greg Sabino Mullane wrote:
If that's what we're trying to solve, I don't think that adding
some kind of proprietary shorthand coding is a good idea. If
we're do to this at all, it should be a connection-based GUC
Peter Eisentraut wrote:
Log Message:
---
Use DocBook XSL stylesheets for man page building
This switches the man page building process to use the DocBook XSL stylesheet
toolchain. The previous targets for Docbook2X are removed. configure has
been
updated to look for the new
David Fetter wrote:
On Tue, Aug 04, 2009 at 10:06:37PM -, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
If that's what we're trying to solve, I don't think that adding
some kind of proprietary shorthand coding is a good idea. If
we're do to this
So, we are just trying to whip into shape explain diagnostics which are
in JSON or XML, and now you want us to exclude XML from this one because
you don't like it? Can we please try for some consistency?
Sorry to break it to you, but there are plenty of people and businesses
who want
I looked at this patch a bit. I haven't actually read any of the code
yet, just reviewed the on-list discussions and the docs, but I think I can
make a few comments at the definitional level.
First: there's already been some discussion about the VIEW problem.
I understand that the patch adds a
On Tue, Aug 4, 2009 at 8:36 PM, Joshua D. Drakej...@commandprompt.com wrote:
So, we are just trying to whip into shape explain diagnostics which are
in JSON or XML, and now you want us to exclude XML from this one because
you don't like it? Can we please try for some consistency?
Sorry to
There's an interesting thread over here
http://archives.postgresql.org/pgsql-sql/2009-08/msg00013.php
in which someone mistook a filesystem-level permissions problem
for a database permissions problem. It wasn't exactly his fault,
I think, since the message he was presented with was
ERROR:
On Tue, Aug 04, 2009 at 09:16:23PM -0400, Robert Haas wrote:
On Tue, Aug 4, 2009 at 8:36 PM, Joshua D. Drakej...@commandprompt.com wrote:
So, we are just trying to whip into shape explain diagnostics which are
in JSON or XML, and now you want us to exclude XML from this one because
you
David Fetter da...@fetter.org writes:
On Tue, Aug 04, 2009 at 09:16:23PM -0400, Robert Haas wrote:
My serialization format kicks your serialization format's butt!
I love standards. There are so many to choose from :)
And the funny thing is that the format we transmit this info to the
client
I am currently trying to convert an insertstmt back into a const
char *queryString, but I can't find an existing function to do this
for the life of me. I will write one if none exits, but I figured I
ask here first. Unfortunately, nodeToString is not quite right
Dan Colish d...@unencrypted.org writes:
I am currently trying to convert an insertstmt back into a const
char *queryString, but I can't find an existing function to do this
for the life of me. I will write one if none exits, but I figured I
ask here first.
On Tue, Aug 04, 2009 at 10:00:24PM -0400, Tom Lane wrote:
Dan Colish d...@unencrypted.org writes:
I am currently trying to convert an insertstmt back into a const
char *queryString, but I can't find an existing function to do this
for the life of me. I will write one if none
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
Sure, I guess I ought to use the latest-and-greatest. Any other comments
before I commit?
That be_pid/be_pid hack in the regression test is pretty ugly, and
doesn't test anything very
1 - 100 of 110 matches
Mail list logo
