Heikki Linnakangas writes:
> Want me to change those or are you on it already?
I'm going to bed --- if you wanna do it, have at it ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
Tom Lane wrote:
> 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 present
Hello
>
> * UBF(B) is a programming langauge for describing types in UBF(A)
> and protocols between clients and servers. UBF(B) is roughly
> equivalent to to Verified XML, XML-schemas, SOAP and WDSL.
>
SOAP is nice sample for Parser Hook -
is soap call there are some immutable field
On Tue, Aug 04, 2009 at 10:55:07PM -0400, Tom Lane wrote:
> Dan Colish writes:
> > On Tue, Aug 04, 2009 at 10:00:24PM -0400, Tom Lane wrote:
> >> Hmm, you mean a Query, or a raw unanalyzed InsertStmt?
>
> > In this case, its a raw InsertStmt. I would like to pass this back to
> > parse_analyze, b
2009/8/5 Alvaro Herrera :
> 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
2009/8/5 Bernd Helmle :
>
>
> --On 4. August 2009 20:22:05 +0200 Pavel Stehule
> 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" va
David Fetter wrote:
> Is it strictly necessary that its release cycles match exactly those
> of the database engine, or would it be OK for it to release as needed,
> not triggering a major PostgreSQL release?
Well, pg_migrator already released an 8.4.1 ...
--
Alvaro Herrera
On Tue, Aug 04, 2009 at 05:19:16PM +0300, Peter Eisentraut wrote:
> 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
On Aug 4, 2009, at 6:30 PM, Tom Lane wrote:
Comments?
+1 Seems like a no-brainer.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dan Colish writes:
> On Tue, Aug 04, 2009 at 10:00:24PM -0400, Tom Lane wrote:
>> Hmm, you mean a Query, or a raw unanalyzed InsertStmt?
> In this case, its a raw InsertStmt. I would like to pass this back to
> parse_analyze, but I need to have a queryString to go with that call, so
> crafting a
On Wed, Aug 5, 2009 at 2:43 AM, Tom Lane wrote:
> And the funny thing is that the format we transmit this info to the
> client in is really the least interesting or difficult part of the
> whole matter ...
That in a nutshell is the problem with XML in the first place.
--
greg
http://mit.edu/~gss
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tom Lane wrote:
> Joe Conway 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
On Tue, Aug 04, 2009 at 10:00:24PM -0400, Tom Lane wrote:
> Dan Colish 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 fi
Dan Colish 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. Unfortunately, nodeToString
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 f
David Fetter 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 in is really
On Tue, Aug 04, 2009 at 09:16:23PM -0400, Robert Haas wrote:
> On Tue, Aug 4, 2009 at 8:36 PM, Joshua D. Drake 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
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: could
On Tue, Aug 4, 2009 at 8:36 PM, Joshua D. Drake 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 break it to yo
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 "G
> 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 wa
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
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
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 GU
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
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
On Tue, Aug 4, 2009 at 11:28 PM, Tom Lane 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 didn't ask for
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost 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 'secur
On Sat, Aug 1, 2009 at 12:35 AM, Alvaro
Herrera 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 unaccent(text) retu
Tom Lane 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 made
> things be
Alvaro Herrera 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.
regards, tom lane
--
Sent
Josh Berkus 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 he was talking
--On 4. August 2009 20:22:05 +0200 Pavel Stehule
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
parameter should be there, an
-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 frag
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_moth&dt=2009-08-04%2020:06:01
>
> I don't have time to look on it now. But it should be reproducible
> everywhere.
It's
> 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,
> a
On Tue, Aug 4, 2009 at 5:23 PM, Tom Lane wrote:
> Robert Haas 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 be
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
> spe
Robert Haas 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 being two cons
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 t
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_moth&dt=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 pgsql-ha
Edson Ramiro 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.
r
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
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
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 rat
Jeff Davis 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 in a SQL stri
On Tue, Aug 4, 2009 at 4:05 PM, Tom Lane wrote:
> Alvaro Herrera 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 a
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 i
Alvaro Herrera 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 these would be used
2009/8/4 Tom Lane :
> Alvaro Herrera 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
Alvaro Herrera 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 it out thoroughly,
Tom Lane wrote:
> Alvaro Herrera 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 refe
2009/8/4 Bernd Helmle :
> --On Montag, August 03, 2009 23:43:08 +0200 Bernd Helmle
> 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
Alvaro Herrera 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 reference
to errcontext callback
On Tue, Aug 4, 2009 at 1:19 PM, Peter Eisentraut 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 it?
>
>
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
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 plann
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
> , for
> this object t
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
* Stephen Frost (sfr...@snowman.net) wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Wed, Jul 22, 2009 at 11:26 PM, Petr Jelinek wrote:
> > > The docs are not complete but that's up to Stephen, otherwise the patch
> > > should be finished. But I am not the reviewer :)
> >
> > Well, pe
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 reservatio
> On Sat, Aug 1, 2009 at 20:30, Kevin Field
> 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 dis
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
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
On Tue, Aug 4, 2009 at 12:01 PM, Tom Lane wrote:
> Robert Haas 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
Bernd Helmle writes:
> --On Samstag, Juli 11, 2009 13:40:44 +0300 Peter Eisentraut
> 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 can look it over in detail.
--On Dienstag, August 04, 2009 10:28:48 -0400 Tom Lane
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
--
Sent via pgsql-hacker
--On Montag, August 03, 2009 23:43:08 +0200 Bernd Helmle
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 discussion.
While poking
Robert Haas 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 you asking for
On Tue, Aug 4, 2009 at 11:44 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Aug 4, 2009 at 10:48 AM, Tom Lane 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
Robert Haas writes:
> On Tue, Aug 4, 2009 at 10:48 AM, Tom Lane 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
have a volunteer to expend the non
Peter Eisentraut 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 AC_TYPE_UINTPTR_T,
Andrew Dunstan 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, create a function ref
On Tue, Aug 4, 2009 at 10:48 AM, Tom Lane wrote:
> Peter Eisentraut 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 n
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 Tuesday 04 August 2009 17:48:12 Tom Lane wrote:
> Peter Eisentraut 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
On Tue, Aug 04, 2009 at 10:45:52AM -0400, Tom Lane wrote:
> Sam Mason 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,
Greg Stark wrote:
On Tue, Aug 4, 2009 at 2:46 PM, Tom Lane 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 st
2009/8/4 Tom Lane :
> Pavel Stehule 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
Magnus Hagander writes:
> On Tue, Aug 4, 2009 at 16:10, Peter Eisentraut 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 changed to use intptr_t and the
Tom Lane wrote:
> Peter Eisentraut 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
>
Peter Eisentraut 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 there wil
Sam Mason 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 samples we have 19
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 t
On Tue, Aug 4, 2009 at 2:46 PM, Tom Lane 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 string that has an
Robert Haas writes:
> On Tue, Aug 4, 2009 at 10:28 AM, Tom Lane 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 similar to
> the one we made for 8.4
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 syste
On Tue, Aug 4, 2009 at 16:31, Robert Haas wrote:
> On Tue, Aug 4, 2009 at 10:28 AM, Tom Lane wrote:
>> Peter Eisentraut 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 cha
On Tue, Aug 4, 2009 at 10:28 AM, Tom Lane wrote:
> Peter Eisentraut 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 d
Peter Eisentraut 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 the
>> de
On Tue, Aug 4, 2009 at 16:06, Peter Eisentraut 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 the HTML file
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 c
Joe Conway 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 like
be
On Tue, Aug 4, 2009 at 16:10, Peter Eisentraut wrote:
> On Tuesday 04 August 2009 14:03:34 Tsutomu Yamada wrote:
>> Robert Haas wrote:
>> > On Fri, Jul 24, 2009 at 4:24 PM, Peter Eisentraut wrote:
>> > > On Friday 26 June 2009 12:07:24 Tsutomu Yamada wrote:
>> > >> Included is a conceptual patc
Tom Lane wrote:
> Alvaro Herrera 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 gets unmaintainable
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
On Tuesday 04 August 2009 14:03:34 Tsutomu Yamada wrote:
> Robert Haas wrote:
> > On Fri, Jul 24, 2009 at 4:24 PM, Peter Eisentraut 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
Pavel Stehule 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 parrot or lua vm, and tra
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
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 tea
1 - 100 of 111 matches
Mail list logo
