I wrote:
> As I said, my inclination for improving this area, if someone wanted
> to work on it, would be to find a way to do truncate-in-place on
> temp tables. ISTM that in the case you're showing --- truncate that's
> not within a subtransaction, on a table that's drop-on-commit anyway
> --- we
On Tue, Aug 4, 2009 at 4:30 AM, Pavel Stehule wrote:
> forward patch to pg_hackers
>
> There is fixed patch. Please, Jaime, can you look on it?
>
this one passed regression tests and my personal test script (of
course it passed the script the last time too)... i'm doing a lot of
alter table [add|d
2009/8/5 Bernd Helmle :
> --On Mittwoch, August 05, 2009 05:28:55 +0200 Pavel Stehule
> wrote:
>
>>> At least, we need to document that both notations behaves different in
>>> this case.
>>
>> +1
>
> Here again a patch version with updated documentation. I will stop reviewing
> this patch now and
Bruce Momjian wrote:
> Andrew Dunstan wrote:
> >
> >
> > Bruce Momjian wrote:
> > > Do we have no composite types in the regression tests, or do we not
> > > store any in the database? Same the enums.
> > >
> > >
> >
> > Looks like the enum regression tests at least drop all their tables :-(
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > Andrew Dunstan writes:
> >
> >> preventing a clash might be fairly difficult.
> >>
> >
> > Yeah, I was just thinking about that. The easiest way to avoid
> > collisions would be to make pg_dump (in --binary-upgrade mode)
> > responsible fo
Andrew Dunstan writes:
> Is there any danger that an oid used in, say, pg_enum in the old version
> will be used in the catalog bootstrap in the new version?
No. All initdb-assigned OIDs are less than 16K, and we never assign
such an OID post-initdb (not even when wrapping around). We might ge
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > Do we have no composite types in the regression tests, or do we not
> > store any in the database? Same the enums.
> >
> >
>
> Looks like the enum regression tests at least drop all their tables :-(
>
> > To allow pg_migrator to work, I w
On Sun, Aug 2, 2009 at 7:29 PM, Andres Freund wrote:
>> Well, the whole explain output format is pretty idiosyncratic, and I
>> had to work pretty hard to beat it into submission. I think that it
>> would not be totally trivial to do what you're suggesting here because
>> it would require adding c
Tom Lane wrote:
Andrew Dunstan writes:
preventing a clash might be fairly difficult.
Yeah, I was just thinking about that. The easiest way to avoid
collisions would be to make pg_dump (in --binary-upgrade mode)
responsible for being sure that *every* new pg_type and pg_class row
OI
Andrew Dunstan writes:
> preventing a clash might be fairly difficult.
Yeah, I was just thinking about that. The easiest way to avoid
collisions would be to make pg_dump (in --binary-upgrade mode)
responsible for being sure that *every* new pg_type and pg_class row
OID matches what it was in the
Bruce Momjian wrote:
Do we have no composite types in the regression tests, or do we not
store any in the database? Same the enums.
Looks like the enum regression tests at least drop all their tables :-(
To allow pg_migrator to work, I would need to reserve the oids in
pg_type, import
Bruce Momjian writes:
> To allow pg_migrator to work, I would need to reserve the oids in
> pg_type, import the dump, and renumber the pg_type entries (and
> everything pointing to them) to the proper pg_type.oid. The big problem
> there is that I don't have access at the SQL level to set or chan
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Hm ... has anyone tested pg_migrator using either composite types or
> >> arrays of user-defined types? Both of them have got user-defined-type
> >> OIDs in on-disk data, now that I think about it. For that matter, enums
> >> are
Tom Lane wrote:
> Bruce Momjian writes:
> > I received the following pg_migrator bug report today and was able to
> > reproduce the reported failure when using composite types:
>
> > test=> SELECT * FROM breakmigrator;
> > ERROR: cache lookup failed for type 27604
>
> Hm ... has anyone
On Wed, Aug 5, 2009 at 6:59 PM, Josh Berkus wrote:
>> As far as the release notes, I think we would have to have proof that
>> the alpha-generated release notes are as good or close to the quality of
>> the release notes using the current process. If they are, we can use
>> them for 8.6, or even f
Alvaro Herrera writes:
> Tom Lane wrote:
>> Hm ... has anyone tested pg_migrator using either composite types or
>> arrays of user-defined types? Both of them have got user-defined-type
>> OIDs in on-disk data, now that I think about it. For that matter, enums
>> are going to be a problem too.
Tom Lane wrote:
> Bruce Momjian writes:
> > I received the following pg_migrator bug report today and was able to
> > reproduce the reported failure when using composite types:
>
> > test=> SELECT * FROM breakmigrator;
> > ERROR: cache lookup failed for type 27604
>
> Hm ... has anyone
"Todd A. Cook" writes:
> Tom Lane wrote:
>> I'm not seeing the very long CPU-bound commit phase that Todd is seeing.
> The commit looks CPU-bound when I let the residual I/O from the function
> execution die out before I issue the commit.
Well, mine is CPU-bound too, it just is much shorter rela
Bruce Momjian writes:
> I received the following pg_migrator bug report today and was able to
> reproduce the reported failure when using composite types:
> test=> SELECT * FROM breakmigrator;
> ERROR: cache lookup failed for type 27604
Hm ... has anyone tested pg_migrator using eit
Bruce,
> As far as the release notes, I think we would have to have proof that
> the alpha-generated release notes are as good or close to the quality of
> the release notes using the current process. If they are, we can use
> them for 8.6, or even for 8.5 if the quality is similar, but we can't
Bruce Momjian wrote:
>
> I received the following pg_migrator bug report today and was able to
> reproduce the reported failure when using composite types:
>
> test=> SELECT * FROM breakmigrator;
> ERROR: cache lookup failed for type 27604
>
> test=> ANALYZE VERBOSE public.bre
I received the following pg_migrator bug report today and was able to
reproduce the reported failure when using composite types:
test=> SELECT * FROM breakmigrator;
ERROR: cache lookup failed for type 27604
test=> ANALYZE VERBOSE public.breakmigrator;
INFO: anal
On Aug 5, 2009, at 4:55 PM, Tom Lane wrote:
Josh Berkus writes:
Josh's position that "this should be standard SQL" is nonsense, or
at least he ought to be making that argument to the standards
committee
not us.
Huh? When did I say that?
Sorry, I think I got one of your messages confu
"Joshua D. Drake" wrote:
>> Tom Lane wrote:
>>
>> > we need something that is alphanumerically less than "beta".
> 1stCF09
> 2ndCF09
> 3rdCF09
Ah, but those would sort higher than letters in EBCDIC
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On Aug 5, 2009, at 3:25 PM, Tom Lane wrote:
Leonardo Cezar writes:
In warm standby system when we have a filled log segment forwarded to
archiving, there is an inconsistency on standby next value sequences
obtained by a call to nextval() function. e.g.:
* Primary server
- Create sequence s
Tom Lane wrote:
So what I'm seeing is entirely explained by the buildup of dead versions
of the temp table's pg_class row --- the index_getnext time is spent
scanning over dead HOT-chain members. It might be possible to avoid
that by special-casing temp tables in TRUNCATE to recycle the existin
On Wed, 2009-08-05 at 16:34 -0500, Kevin Grittner wrote:
> Tom Lane wrote:
>
> > we need something that is alphanumerically less than "beta".
>
> antebeta1?
>
> Then, each commit-fest, we up the ante
1stCF09
2ndCF09
3rdCF09
>
> -Kevin
>
--
PostgreSQL - XMPP: jdr...@jabber.postgres
"Kevin Grittner" writes:
> Tom Lane wrote:
>> we need something that is alphanumerically less than "beta".
> antebeta1?
> Then, each commit-fest, we up the ante
rotfl...
Actually just "ante1" would work better for that joke.
regards, tom lane
--
Sent via pgsq
Tom Lane wrote:
> we need something that is alphanumerically less than "beta".
antebeta1?
Then, each commit-fest, we up the ante
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
Bruce Momjian wrote:
I would much rather
they be called Commit Feast 1 (CF1), or something like that.
ITYM "Fest", although sometimes we make a meal of it ;-)
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
--On Mittwoch, August 05, 2009 05:28:55 +0200 Pavel Stehule
wrote:
At least, we need to document that both notations behaves different in
this case.
+1
Here again a patch version with updated documentation. I will stop
reviewing this patch now and mark this ready for committer, so we have
> As far as the alpha releases, I am still worried about the use of the
> word "alpha". I am worried someone is going to look at 8.4alpha1 and
> think that represents most of the features that will be in 8.5final, and
> will think the Postgres project is losing momentum. I would much rather
> the
Bruce Momjian writes:
> As far as the alpha releases, I am still worried about the use of the
> word "alpha". I am worried someone is going to look at 8.4alpha1 and
> think that represents most of the features that will be in 8.5final, and
> will think the Postgres project is losing momentum. I
On Wed, 2009-08-05 at 17:11 -0400, Bruce Momjian wrote:
> Josh Berkus wrote:
> As far as the alpha releases, I am still worried about the use of the
> word "alpha". I am worried someone is going to look at 8.4alpha1 and
> think that represents most of the features that will be in 8.5final, and
>
Josh Berkus wrote:
>
> > What I would like to avoid is a situation where we're basically ready
> > to go with beta and Bruce says, "Hold on, everybody, it's going to
> > take another two weeks while I plow through 600 commit messages." I
> > have a theory that that work can be spread out and much
Josh Berkus writes:
>> Josh's position that "this should be standard SQL" is nonsense, or
>> at least he ought to be making that argument to the standards committee
>> not us.
> Huh? When did I say that?
Sorry, I think I got one of your messages confused with one of Robert's.
Anyway,
> *Buil
"Kevin Grittner" writes:
> Tom Lane wrote:
>> "Todd A. Cook" writes:
>>> I've noticed that on 8.4.0, commits can take a long time when a
>>> temp table is repeatedly filled and truncated within a loop.
>> The commit time doesn't seem tremendously out of line, but it looks
>> like there's somet
> Josh's position that "this should be standard SQL" is nonsense, or
> at least he ought to be making that argument to the standards committee
> not us.
Huh? When did I say that?
> If we want something built-in, maybe providing some prefab plpgsql
> functions is the way to go. But we'd have
> What I would like to avoid is a situation where we're basically ready
> to go with beta and Bruce says, "Hold on, everybody, it's going to
> take another two weeks while I plow through 600 commit messages." I
> have a theory that that work can be spread out and much of it done in
> advance and
Tom Lane wrote:
> "Todd A. Cook" writes:
>> I've noticed that on 8.4.0, commits can take a long time when a
>> temp table is repeatedly filled and truncated within a loop.
> The commit time doesn't seem tremendously out of line, but it looks
> like there's something O(N^2)-ish in the function e
2009/8/5 Tom Lane :
> Robert Haas writes:
>> I have one database that is set up with a reporting user (read only on
>> everything). It requires constant maintenance. Every time an object
>> is added or deleted (or dropped and recreated, like a view, which I do
>> ALL THE TIME to work around the
"Todd A. Cook" writes:
> I've noticed that on 8.4.0, commits can take a long time when a temp table is
> repeatedly
> filled and truncated within a loop. A very contrived example is
Hmm. I tweaked the function to allow varying the number of truncates:
regression=# begin;
BEGIN
Time: 1.037 ms
On Wed, Aug 5, 2009 at 3:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> I have one database that is set up with a reporting user (read only on
>> everything). It requires constant maintenance. Every time an object
>> is added or deleted (or dropped and recreated, like a view, which I do
>> ALL
Robert Haas writes:
> I have one database that is set up with a reporting user (read only on
> everything). It requires constant maintenance. Every time an object
> is added or deleted (or dropped and recreated, like a view, which I do
> ALL THE TIME to work around the inability to add/remove co
2009/8/5 Tom Lane :
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> Peter pointed out upthread that the SQL standard already calls out some
>>> things that should be available in this way --- has anyone studied that
>>> yet?
>
>> Yeah, I gave it a look. It looks useful as a guide, though obviousl
Alvaro Herrera writes:
> Tom Lane wrote:
>> Peter pointed out upthread that the SQL standard already calls out some
>> things that should be available in this way --- has anyone studied that
>> yet?
> Yeah, I gave it a look. It looks useful as a guide, though obviously
> not directly implementab
On Wed, 2009-08-05 at 12:34 -0400, Robert Haas wrote:
> Oleg,
>
> Are you planning to update this patch this week? If not I will set it
> to "Returned with Feedback".
My only comments were related to docs and comments, and I supplied a
patch as a suggested fix for the docs. Also, the patch is ve
Leonardo Cezar writes:
> In warm standby system when we have a filled log segment forwarded to
> archiving, there is an inconsistency on standby next value sequences
> obtained by a call to nextval() function. e.g.:
> * Primary server
> - Create sequence seq_a;
> - Select nextval ( 'seq_a'); # va
Tom Lane wrote:
> Peter pointed out upthread that the SQL standard already calls out some
> things that should be available in this way --- has anyone studied that
> yet?
Yeah, I gave it a look. It looks useful as a guide, though obviously
not directly implementable because it relies on GET DIAG
On Wed, Aug 5, 2009 at 2:57 PM, Josh Berkus wrote:
> Right now we have a situation where most web developers aren't using
> ROLEs *at all* because they are too complex for them to bother with. I
> literally couldn't count the number of production applications I've run
> across which connect to Pos
On Wed, Aug 5, 2009 at 1:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> Between now and then, I'm going to be working on identifying which
>> patches are not marked as "Waiting on Author" but should be, or which
>> are marked as "Waiting on Author" but shouldn't be.
>
> Er, shouldn't you first wo
Hi,
In warm standby system when we have a filled log segment forwarded to
archiving, there is an inconsistency on standby next value sequences
obtained by a call to nextval() function. e.g.:
* Primary server
- Create sequence seq_a;
- Select nextval ( 'seq_a'); # value 1;
- Log shipping;
* Stand
Tom,
> I took a quick look at this version of the patch. Other than the
> already-mentioned question of whether we really want to create a
> distinction between tables and views in GRANT, there's not that
> much there to criticize.
It's pretty common to have a database where there are some users
2009/8/5 Tom Lane :
> Sam Mason writes:
>> On Wed, Aug 05, 2009 at 12:41:30PM -0500, Kevin Grittner wrote:
>>> Anyway, it was a bad suggestion that we provide a way to specify a
>>> SQLSTATE to use for a constraint failure. I do think that some field
>>> which could be used for that purpose would
Sam Mason wrote:
> Still doesn't really describe the
> engineering rational behind it though.
Well, the distinctions in many cases would be mostly of interest to a
DBA managing a large shop who was trying to characterize the reasons
for query failure. Some codes, however, are particularly va
Tom Lane wrote:
I do have a feeling that the implementation
is a bit too narrowly focused on the "stuff IN SCHEMA foo" case;
if we were ever to add other filtering options it seems like we'd
have to rip all this code out and start over. But I don't have any
immediate ideas on what it should look
Sam Mason writes:
> On Wed, Aug 05, 2009 at 12:41:30PM -0500, Kevin Grittner wrote:
>> From the table, the 23xxx series is for integrity constraint
>> violations, but they appear not to have gotten too specific about
>> breaking that down; thereby leaving it as an implementation choice:
> Yes; bu
Sam Mason writes:
> On Wed, Aug 05, 2009 at 12:41:30PM -0500, Kevin Grittner wrote:
>> Anyway, it was a bad suggestion that we provide a way to specify a
>> SQLSTATE to use for a constraint failure. I do think that some field
>> which could be used for that purpose would be good. Preferably
>> s
On Wed, Aug 05, 2009 at 12:41:30PM -0500, Kevin Grittner wrote:
> From the spec:
>
> "The character string value returned in an SQLSTATE parameter
> comprises a 2-character class value followed by a 3-character subclass
> value, each with an implementation-defined character set that has a
> one-oc
I wrote:
> kar...@sao.ru (Sergey V. Karpov) writes:
>> Andres Freund writes:
>>> Looks nice. The only small gripe I have is that the patch adds trailing
>>> whitespaces at a lot of places...
>> My fault. Please check the patch version attached - I've tried to fix
>> all those.
> I did some mino
Hi,
I've noticed that on 8.4.0, commits can take a long time when a temp table is
repeatedly
filled and truncated within a loop. A very contrived example is
begin;
create or replace function commit_test_with_truncations()
returns void
language 'plpgsql'
as $_func_$
declare
Robert Haas writes:
> Between now and then, I'm going to be working on identifying which
> patches are not marked as "Waiting on Author" but should be, or which
> are marked as "Waiting on Author" but shouldn't be.
Er, shouldn't you first work on finishing your own patches? The EXPLAIN
output pa
Sam Mason wrote:
> It just looks like a fixed set of numbers for a fixed set of
> conditions, can't find any canonical definition about what it's
> really for though.
Sorry, I'm familiar with the SQLSTATE's role in the spec, I just
wasn't sure how specific they got in their table of standard v
Petr Jelinek writes:
> One more typo fix in docs
I took a quick look at this version of the patch. Other than the
already-mentioned question of whether we really want to create a
distinction between tables and views in GRANT, there's not that
much there to criticize. I do have a feeling that th
On Wed, Aug 05, 2009 at 11:32:06AM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > Not sure if overloading SQLSTATE is the right way of doing this is
> > it? It already has things like 23514 for a check violation and any
> > other client code relying in this would break if it started getting
Robert Haas writes:
> ... bulk-grant could be based on object type,
> object name (with wildcard or regexp pattern), schema membership, or
> maybe other things, and I think that would be quite useful if we can
> figure out how to make it clean and elegant.
Yeah. In the end you can always write a
On Wed, Aug 5, 2009 at 12:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> My understanding is that this patch will need to be reworked as well
>> based on Tom's comments on "DefaultACLs". Does that sound right?
>> Should we expect a new version this week, or defer this until the
>> September Comm
Tom Lane wrote:
I'm not sure whether there is consensus on not using GRANT ON VIEW
(ie, having these patches treat tables and views alike). I was waiting
to see if Stephen would put forward a convincing counterargument ...
Conceptually it is right, I think. A view is a virtual table, so
Folks,
We now have just 10 days left in this CommitFest and I think it is
time to start thinking about closing up shop. My tentative plan,
absent strong objections, is to wait until Friday night and then move
most or all of the patches that are still "Waiting on Author" to
"Returned with Feedback
Robert Haas writes:
> My understanding is that this patch will need to be reworked as well
> based on Tom's comments on "DefaultACLs". Does that sound right?
> Should we expect a new version this week, or defer this until the
> September CommitFest?
I was planning to go review that patch too, ev
On Sun, Aug 2, 2009 at 3:05 PM, Jeff Davis wrote:
> The patch looks good.
>
> Comments:
>
> 1. The docs should be clarified a little. For instance, it should have a
> link back to the definition of a prefix search (12.3.2). I included my
> doc suggestions as an attachment.
>
> 2. dsynonym_init() us
On Mon, Jul 20, 2009 at 2:12 AM, Nikhil
Sontakke wrote:
> The review is complete from my side. There is this question about
> consistency between this patch and the Defaultacls patch. But am ok
> with this patch on its own. So ready for committer from my side.
My understanding is that this patch w
Sam Mason wrote:
> Not sure if overloading SQLSTATE is the right way of doing this is
> it? It already has things like 23514 for a check violation and any
> other client code relying in this would break if it started getting
> different things back.
If that's the standard SQLSTATE, I agree -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tom Lane wrote:
> Could you do something like
> be_pid = pg_backend_pid() AS is_self_notify
> instead, to verify that it's a self-notify? (This is not quite right
> because you'd need to execute pg_backend_pid() at the remote end, but
> I'm no
On Wed, Aug 05, 2009 at 09:30:02AM -0500, Kevin Grittner wrote:
> Anyway, the upshot is -- I think that it would be beneficial to allow,
> to the extent we can confirm it's not a violation of any applicable
> standard, a user-defined SQLSTATE to be associated with a constraint.
> I also think that
Thanks for help
Edson Ramiro
On Tue, Aug 4, 2009 at 17:49, Tom Lane wrote:
> 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?
>
> On
Tom Lane escribió:
> Well, it'd mainly be a question of whether there's enough interest out
> there, which I can't judge. From a project standpoint we just require
> that it be BSD-licensed and not impose any undue new burden on
> maintainers (thus not wanting new build tools), but beyond that it
Werner Echezuria writes:
> Well, I use TextDatumGetCString in the main file, but it remains with the
> weird characters.
Hmm, no ideas then. Your interface code looks fine (making parse_str
const seems a bit strange, but it's not related to the problem at hand).
Given that the problems appear at
Hi,
Well, I use TextDatumGetCString in the main file, but it remains with the
weird characters.
this is the main file:
#include "postgres.h"
#include "fmgr.h"
#include "gram.h"
#include "sqlf.h"
#include "utils/builtins.h"
extern Datum sqlf(PG_FUNCTION_ARGS);
PG_MODULE_MAGIC;
PG_FUNCTION_INFO
Tom Lane wrote:
> Heikki Linnakangas writes:
>> I note that many of the messages currently print the relpath() of the
>> relation, and don't include the affected segment suffix. For example:
>
>> could not read block 14 of relation base/11566/24614: read only 1
>> of 8192 bytes
>
>> If we c
Petr Jelinek writes:
> Tom Lane wrote:
>> What I suggest as a way to resolve this last point is that a default ACL
>> should apply only to objects owned by the user who creates/modifies the
>> default ACL. In this view, the question of which schema the objects are
>> in is just an additional filt
Magnus Hagander writes:
>>> But. I'll look into cleaning those up for HEAD anyway, but due to lack
>>> of reports I think we should skip backpatch. Reasonable?
>>
>> Fair enough.
> Here's what I came up with. Seems ok?
Works for me.
regards, tom lane
--
Sent via pgsql
Heikki Linnakangas writes:
> I note that many of the messages currently print the relpath() of the
> relation, and don't include the affected segment suffix. For example:
> could not read block 14 of relation base/11566/24614: read only 1
> of 8192 bytes
> If we change them to point to the
2009/8/5 Magnus Hagander :
> Since Alvaro is talking about error messages in another thread, I
> figured I should post this idea now as well.
>
> Something that keeps annoying me a lot when trying to look through
> what comes out of PostgreSQL logs is that errors generated by the user
> (syntax err
Boszormenyi Zoltan írta:
> Michael Meskes írta:
>
>> On Wed, Aug 05, 2009 at 11:08:26AM +0200, Boszormenyi Zoltan wrote:
>>
>>
>>> I have looked at it. The code seems to be invalid.
>>>
>>>
>> Yes, it is, I was too lazy to make it valid. If you just allocate the memory
>> for
On Aug 4, 2009, at 11:10 PM, Tom Lane wrote:
Want me to change those or are you on it already?
I'm going to bed --- if you wanna do it, have at it ...
Oh please. Everyone knows that you don't sleep, Tom. You just sit back
in your chair and power nap for five minutes once in a while, perhap
Werner Echezuria writes:
> I'm trying to develop a contrib module in order to parse sqlf queries, I'm
> using lemon as a LALR parser generator (because I think it's easier than
> bison) and re2c (because I think it's easier than flex) but when I try to
> split the string into words postgres add so
Sam Mason wrote:
> On Wed, Aug 05, 2009 at 01:29:13PM +0200, Pavel Stehule wrote:
>> When you have a full set of constraint, then you don't need to
>> validate input. Just you will execute statement.
>
> Constraints are different from input validation as they rely on
> state that the database'
Michael Meskes írta:
> On Wed, Aug 05, 2009 at 03:04:00PM +0200, Boszormenyi Zoltan wrote:
>
>> My question is: why not unroll the struct in the preprocessor?
>>
>
> The problem is not that the struct is unrolled in the preprocessor. I just
> don't like the idea of having two places where s
Michael Meskes írta:
> On Wed, Aug 05, 2009 at 11:08:26AM +0200, Boszormenyi Zoltan wrote:
>
>> I have looked at it. The code seems to be invalid.
>>
>
> Yes, it is, I was too lazy to make it valid. If you just allocate the memory
> for the variable in get_var() it becomes valid.
>
If y
Robert Haas writes:
> (2) Is it worth making this work?
No, I don't think so. The odds of such a test ever showing anything
interesting seem minimal.
plpgsql's inability to cope with the case would be nice to fix, but
I'm not holding my breath for it...
regards, tom lan
Magnus Hagander wrote:
> Something that keeps annoying me a lot when trying to look through
> what comes out of PostgreSQL logs is that errors generated by the user
> (syntax errors in queries, warnings due to incorrect string escaping,
> statements terminated due to timeout etc etc) are intermixed
On Wed, Aug 5, 2009 at 9:02 AM, Michael Meskes wrote:
>> I confess I haven't been following the ECPG threads real closely, but
>> I'm confused as to the status of the following two patches. Have you
>> reviewed these? If so, what was the outcome? If not, do you plan to?
>
> I did a first review
Magnus Hagander writes:
> I'd like to add another field to messages called "source" (not wedded
> to the name). Initially, this could just be "user" and "internal", but
> I can see a use-case in the future for it to differ between for
> example "archiver" and "bgwriter" (it's certainly not unheard
On Wed, Aug 05, 2009 at 03:04:00PM +0200, Boszormenyi Zoltan wrote:
> My question is: why not unroll the struct in the preprocessor?
The problem is not that the struct is unrolled in the preprocessor. I just
don't like the idea of having two places where structs are unrolled when one
could be suff
Hi,
I'm trying to develop a contrib module in order to parse sqlf queries, I'm
using lemon as a LALR parser generator (because I think it's easier than
bison) and re2c (because I think it's easier than flex) but when I try to
split the string into words postgres add some weird characters (this wor
Tom Lane wrote:
> 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 ...
Ok.
I note that many of the messages currently print the relpath() of the
relation, and don't include the affected segment suffix. For ex
On Wed, Aug 5, 2009 at 09:24, Peter Eisentraut wrote:
> So the next step to documentation bliss is to get rid of the man.tar.gz and
> postgres.tar.gz tarballs that are shipped inside the tarball. These are
> historical artifacts from the era when building the documentation for release
> required m
Peter Eisentraut wrote:
> On Wednesday 05 August 2009 02:43:19 Alvaro Herrera wrote:
> > I'm wondering if dropping SPI_* manpages is really what we want. Maybe
> > we could add them to man section 3? I know I've wanted to have them a
> > couple of times.
> >
> > Not sure about dblink.
>
> This w
Michael Meskes írta:
>> I confess I haven't been following the ECPG threads real closely, but
>> I'm confused as to the status of the following two patches. Have you
>> reviewed these? If so, what was the outcome? If not, do you plan to?
>>
>
> I did a first review and then left for my vaca
1 - 100 of 123 matches
Mail list logo
