2012/12/28 Gavin Flower :
> On 29/12/12 10:19, Peter Eisentraut wrote:
>
> On 12/28/12 11:22 AM, Pavel Stehule wrote:
>
> I am not sure, but maybe is time to introduce ANSI SQL syntax for
> functions' named parameters
>
> It is defined in ANSI SQL 2011
>
> CALL P (B => 1, A => 2)
>
> instead Postg
> "TL" == Tom Lane writes:
JC>> Is there any contraindication to recasting:
JC>> foo ILIKE 'bar'
JC>> into:
JC>> LOWER(foo) LIKE LOWER('bar')
TL> In some locales those are not equivalent, I believe, or at least
TL> shouldn't be. (What the current code actually does is a separate
TL> questio
Attached is a cumulative patch attempting to address the below. One
can see the deltas to get there at https://github.com/fdr/postgres.git
error-prop-pg_stat_statements-v2.
On Fri, Dec 28, 2012 at 9:58 AM, Peter Geoghegan wrote:
> However, with this approach, calls_underest values might appear t
The xlog code uses two different time zone formats at various times.
Here is an example:
2012-12-29 07:04:07.338 EST LOG: database system was interrupted; last known
up at 2012-12-29 06:27:02 EST
2012-12-29 07:04:26.347 EST LOG: last completed transaction was at log time
2012-12-29 06:34:24.39
On 2012-12-29 07:23:24 -0500, Peter Eisentraut wrote:
> The xlog code uses two different time zone formats at various times.
> Here is an example:
>
> 2012-12-29 07:04:07.338 EST LOG: database system was interrupted; last known
> up at 2012-12-29 06:27:02 EST
> 2012-12-29 07:04:26.347 EST LOG: l
On Tue, Dec 25, 2012 at 10:34 AM, Dimitri Fontaine
wrote:
> Thank you for this partial commit, and Simon and Andres to fill in the
> gaps. I should mention that the missing header parts were all in my
> patch, and that headers hacking is proving suprisingly uneasy.
Apologies to all about the miss
On Sat, Dec 29, 2012 at 4:21 AM, Daniel Farina wrote:
> These were not express goals of the patch, but so long as you are
> inviting features, attached is a bonus patch that exposes the queryid
> and also the notion of a "statistics session" that is re-rolled
> whenever the stats file could not be
On Tue, Dec 25, 2012 at 1:42 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> Also, keep in mind we want the ObjectID in all CREATE, ALTER and DROP
>>> statements, so my current patch is still some bricks shy of a load… (I
>>> added ObjectID only in the commands I added rewrite support for,
Robert Haas writes:
> If I thought there were some useful code, I would try to see if we
> could contribute it, but I'm pretty sure there isn't. We have a bunch
Oh. Too bad.
[... description of the tool ...]
> I don't see a way to do the exact kind of testing we need here in a
> cross-platform
Robert Haas writes:
> OK, I committed this.
Thanks. Please find attached a rebased patch, v6. I think it's looking
more like what you would expect now:
COLUMNS=70 git diff --stat postgres/master..
doc/src/sgml/event-trigger.sgml | 196 +++-
doc/src/sgml/plpgsql.sgml
On Fri, Dec 28, 2012 at 11:41 PM, Tom Lane wrote:
> James Cloos writes:
>> Is there any contraindication to recasting:
>> foo ILIKE 'bar'
>> into:
>> LOWER(foo) LIKE LOWER('bar')
>
> In some locales those are not equivalent, I believe, or at least
> shouldn't be. (What the current code actua
Fabrízio de Royes Mello writes:
> Event triggers don't cover "CREATE DATABASE" statement.
The reason why is because you create Event Triggers in a specific
database and they only get run when you happen to be connected to that
specific database.
So for example say you install your Event Trigger
On Sat, Dec 29, 2012 at 2:05 PM, Greg Stark wrote:
> I can't quite wrap my head around the idea of "LIKE" and collations
> having any meaningful interaction anyways. I certainly can't come up
> with anything better than "lower() like lower()" (or "upper() like
> upper()").
Hm. Maybe I spoke too f
Dimitri,
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> I personnaly think that given a good documentation coverage having Event
> Trigger on global objects could be useful enough, even if you would have
> to install them in every database when you want them to fire no matter
> what.
I disa
Stephen Frost writes:
> I disagree. If we're going to have what are essentially 'global' event
> triggers, then they should go into a shared catalog- the user shouldn't
> be required to install them everywhere to get coverage. In addition,
I understand your view point, and if we think we will b
On 12/29/2012 08:41 AM, Dimitri Fontaine wrote:
Well, do we have \! in psql in windows at all? does it work in a similar
way to the unix one? I just don't know.
Of course we do, Why ever would you think we don't? The command must be
written in the Windows shell language, but the behaviour i
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> It sounds to me like either autonomous transaction with the capability
> to run the independant transaction in another database, or some dblink
> creative use case. Another approach would be to get plproxy into core
> as a Foreign Data Wrapper fo
On 2012-12-29 09:59:49 -0500, Stephen Frost wrote:
> * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> > It sounds to me like either autonomous transaction with the capability
> > to run the independant transaction in another database, or some dblink
> > creative use case. Another approach would
* Andres Freund (and...@2ndquadrant.com) wrote:
> I don't think autonomous transactions are the biggest worry
> here. Transactions essentially already span multiple databases, so thats
> not really a problem in this context. Making it possible to change
> catalogs while still being active in anothe
On 29 December 2012 05:04, Pavel Stehule wrote:
> again - it is reason why I propose ROUTINE_NAME and TRIGGER_NAME - it
> can be useful for some use cases, where developer should to handle
> exception when they coming from known functions/triggers and he would
> to raise exception, when it was rai
Andres Freund writes:
> On 2012-12-29 07:23:24 -0500, Peter Eisentraut wrote:
>> The xlog code uses two different time zone formats at various times.
> One is a pg_time_t (stored in pg_control/ControlFileData), the other is
> a TimestampTz. Those have completely different code paths for being
> p
On 27.12.2012 22:46, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Might be cleaner to directly assign the correct value to MaxBackends
above, ie. "MaxBackends = MaxConnections + newval + 1 +
GetNumShmemAttachedBgworkers()". With a comment to remind that it
needs to be kept in sync with the
Robert Haas writes:
> The other danger here is - what exactly do you mean by "no command has
> been able to run between the user command and our lookup"? Because
> you can do stupid things with functions like set_config(). This would
> only be safe if no user-provided expressions can possibly ge
Peter Geoghegan writes:
> On 29 December 2012 05:04, Pavel Stehule wrote:
>>> So I'm with Peter G on this: the existing CONTEXT mechanism is good
>>> enough, we do not need to split out selected sub-parts of that as
>>> separate error fields. Moreover, doing so would provide only an utterly
>>>
2012/12/29 Peter Geoghegan :
> On 29 December 2012 05:04, Pavel Stehule wrote:
>> again - it is reason why I propose ROUTINE_NAME and TRIGGER_NAME - it
>> can be useful for some use cases, where developer should to handle
>> exception when they coming from known functions/triggers and he would
>>
2012/12/29 Tom Lane :
> Peter Geoghegan writes:
>> On 29 December 2012 05:04, Pavel Stehule wrote:
So I'm with Peter G on this: the existing CONTEXT mechanism is good
enough, we do not need to split out selected sub-parts of that as
separate error fields. Moreover, doing so would
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> On 28 December 2012 15:57, Tom Lane wrote:
> > I don't think that part's been agreed to at all; it seems entirely
> > possible that it'll get dropped if/when the patch gets committed.
> > I'm not convinced that having these fields in the log is wo
On 29 December 2012 17:43, Stephen Frost wrote:
> I'd like to see more options for what is logged, as I've mentioned in
> the past, and I think all of these would be good candidates for logging
> in some circumstances. The insistence on having one CSV format to rule
> them all and which doesn't c
2012/12/29 Peter Geoghegan :
> On 29 December 2012 17:43, Stephen Frost wrote:
>> I'd like to see more options for what is logged, as I've mentioned in
>> the past, and I think all of these would be good candidates for logging
>> in some circumstances. The insistence on having one CSV format to r
Peter,
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> Pavel originally included a
> constraint_schema field, because he figured that the way constraints
> are catalogued necessitated such a field.
That's exactly what I was getting at also- in order to do a lookup in
the catalog, you need to k
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> I found so we doesn't have functionality for simply text aligning - so
> I propose support width for %s like printf's behave. glibc
> implementation knows a rule for precision, that I don't would to
> implement, because it is oriented to by
Hello
2012/12/29 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> I found so we doesn't have functionality for simply text aligning - so
>> I propose support width for %s like printf's behave. glibc
>> implementation knows a rule for precision, that I don't would to
* Jon Erdman (postgre...@thewickedtribe.net) wrote:
> Oops! Here it is in the proper diff format. I didn't have my env set up
> correctly :(
No biggie, and to get the bike-shedding started, I don't really like the
column name or the values.. :) I feel like something clearer would be
"Runs_As" wi
On 30/12/12 05:24, Tom Lane wrote:
Andres Freund writes:
On 2012-12-29 07:23:24 -0500, Peter Eisentraut wrote:
The xlog code uses two different time zone formats at various times.
One is a pg_time_t (stored in pg_control/ControlFileData), the other is
a TimestampTz. Those have completely diff
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2012/12/29 Stephen Frost :
> > This is correct, if we're matching glibc (and SUS, I believe), isn't it?
> > You're not allowed to mix '%2$s' type parameters and '%s' in a single
> > format.
>
> I am not sure, please recheck
According to t
* Pavan Deolasee (pavan.deola...@gmail.com) wrote:
> On Fri, Sep 7, 2012 at 6:06 PM, Kevin Grittner
> > That makes sense to me. The reason I didn't make that change when I
> > added the serializable special case to pg_dump was that it seemed
> > like a separate question; I didn't want to complicat
2012/12/29 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> 2012/12/29 Stephen Frost :
>> > This is correct, if we're matching glibc (and SUS, I believe), isn't it?
>> > You're not allowed to mix '%2$s' type parameters and '%s' in a single
>> > format.
>>
>> I am not
Pavan,
* Pavan Deolasee (pavan.deola...@gmail.com) wrote:
> On Tue, Dec 4, 2012 at 6:01 PM, Pavan Deolasee
> wrote:
> > Thanks Andres. I also read the original thread and I now understand why we
> > are using FATAL here, at least until we have a better solution. Obviously
> > the connection reset
On 29 December 2012 18:37, Stephen Frost wrote:
> That's exactly what I was getting at also- in order to do a lookup in
> the catalog, you need to know certain information to avoid potentially
> getting multiple records back (which would be an error...).
Well, Pavel said that since a constraint i
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> ok, so what is proposed solution?
My recommendation would be to match what glibc's printf does.
> I see two possibilities - a) applying my current patch - although it
> is not fully correct, b) new patch, that do necessary check and raise
> more
2012/12/29 Peter Geoghegan :
> On 29 December 2012 18:37, Stephen Frost wrote:
>> That's exactly what I was getting at also- in order to do a lookup in
>> the catalog, you need to know certain information to avoid potentially
>> getting multiple records back (which would be an error...).
>
> Well,
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> So, unless someone adds a constraint name outside of these errcodes (I
> doubt that would make sense), there is exactly one case where a
> constraint_name could not have a schema_name (which, as I've said, is
> almost the same thing as constraint_s
2012/12/29 Stephen Frost :
> * Peter Geoghegan (pe...@2ndquadrant.com) wrote:
>> So, unless someone adds a constraint name outside of these errcodes (I
>> doubt that would make sense), there is exactly one case where a
>> constraint_name could not have a schema_name (which, as I've said, is
>> almo
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> > Having just constraint_schema and constraint_name feels horribly wrong
> > as the definition of a constraint also includes a pg_class oid.
>
> but then TABLE_NAME and TABLE_SCHEMA will be defined.
How are you going to look up the constraint? U
2012/12/29 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> > Having just constraint_schema and constraint_name feels horribly wrong
>> > as the definition of a constraint also includes a pg_class oid.
>>
>> but then TABLE_NAME and TABLE_SCHEMA will be defined.
>
> How are you
Josh,
* Josh Kupershmidt (schmi...@gmail.com) wrote:
> I assume you meant "-L" instead of "-l" here for specifying psql's log
> file. I don't think that the inability to write to psql's log file
> should be treated as a fatal error, especially since it is not treated
> as such by the current code:
On 29 December 2012 19:56, Stephen Frost wrote:
>> - that case is
>> ERRCODE_CHECK_VIOLATION.
>>
>> That's because this SQL could cause ERRCODE_CHECK_VIOLATION:
>>
>> select '123'::upc_barcode;
>
> I'm surprised to see that as a constraint violation rather than a domain
> violation..?
I was tryin
Alastair,
* Alastair Turner (b...@ctrlf5.co.za) wrote:
> Patch for the changes discussed in
> http://archives.postgresql.org/pgsql-hackers/2010-10/msg00919.php
> attached (eventually ...)
>
> In summary: If the input file (-f) doesn't exist or the ouput or log
> files (-o and -l) can't be created
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> > Having just constraint_schema and constraint_name feels horribly wrong
> > as the definition of a constraint also includes a pg_class oid.
>
> I think that it's probably sufficient *for error handling purposes*.
> Since it is non-trivial to get
The cascading replication patch made a change to the way WAL files
restored from archive are handled. Since then, when a WAL file is
restored from archive, it's copied under the correct filename to
pg_xlog. Aside from supporting cascading replication, this has the
advantage that if the archive
On 02.10.2012 21:20, Fujii Masao wrote:
On Wed, Oct 3, 2012 at 3:11 AM, Simon Riggs wrote:
but its not high on my radar
right now unless you can explain why it should be higher.
It may not be high, but I'm just worried that we are likely to forget to
apply that change into HEAD if we postpone
2012/12/29 Stephen Frost :
> * Peter Geoghegan (pe...@2ndquadrant.com) wrote:
>> > Having just constraint_schema and constraint_name feels horribly wrong
>> > as the definition of a constraint also includes a pg_class oid.
>>
>> I think that it's probably sufficient *for error handling purposes*.
>
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> it is a problem of this patch or not consistent constraints implementation ?
Not sure, but I don't think it matters. You can blame the constraint
implementation, but that doesn't change my feelings about what we need
before we can accept a patch
2012/12/29 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> it is a problem of this patch or not consistent constraints implementation ?
>
> Not sure, but I don't think it matters. You can blame the constraint
> implementation, but that doesn't change my feelings about what we
On 29 December 2012 20:49, Stephen Frost wrote:
> In the end, I may agree with you- the patch is a nice idea, but it needs
> more to be a complete and working solution and providing something that
> only gets people half-way there would result in developers hacking
> things together which will qui
On 29 December 2012 21:24, Pavel Stehule wrote:
> can we remove CONSTRAINT_NAME from this patch? Minimally TABLE_SCHEMA,
> TABLE_NAME and COLUMN_NAME works as expected.
>
> CONSTRAINT_NAME can be implemented after constraints refactoring
This patch is almost completely pointless without a CONSTRA
Peter,
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> if (constraint_name == "upc")
> MessageBox("That is not a valid barcode.");
So they'll quickly realize that a lookup-table based on constraint name
would be useful, create it, and then have a primary key on it to make
sure that they do
On 29 December 2012 22:57, Stephen Frost wrote:
> So they'll quickly realize that a lookup-table based on constraint name
> would be useful, create it, and then have a primary key on it to make
> sure that they don't have any duplicates.
I don't find that terribly likely. There is nothing broken
Peter,
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> In order for the problem you describe to happen, the user would have
> to ignore the warning in the documentation about constraint_name's
> ability to uniquely identify something, and then have two constraints
> in play at the same time wit
On 29 December 2012 12:21, Daniel Farina wrote:
> These were not express goals of the patch, but so long as you are
> inviting features, attached is a bonus patch that exposes the queryid
> and also the notion of a "statistics session" that is re-rolled
> whenever the stats file could not be read
On Sat, Dec 29, 2012 at 6:37 PM, Peter Geoghegan wrote:
> On 29 December 2012 12:21, Daniel Farina wrote:
>> These were not express goals of the patch, but so long as you are
>> inviting features, attached is a bonus patch that exposes the queryid
>> and also the notion of a "statistics session"
On Thu, Dec 27, 2012 at 11:33 AM, Tom Lane wrote:
> Greg Stark writes:
>> On Thu, Dec 27, 2012 at 3:17 AM, Tom Lane wrote:
>>> The thing that this theory has a hard time with is that the buffer's
>>> global refcount is zero. If you assume that there's a bit that
>>> sometimes randomly goes to 1
On 30 December 2012 02:01, Stephen Frost wrote:
> I really don't think what I sketched out or something similar would
> happen. I do think it's incredibly frustrating as a user who is trying
> to develop an application which behaves correctly to be given only half
> the information.
I don't know
On Sun, Dec 23, 2012 at 8:41 PM, Tomas Vondra wrote:
> Attached is a patch with fixed handling of temporary relations. I've
> chosen to keep the logic in DropRelFileNodeAllBuffers and rather do a
> local copy without the local relations.
This looks pretty good, although it needs some cleanup for
On 12/27/12 7:43 AM, Greg Stark wrote:
If it's always the first buffer then it could conceivably still be
some other heap allocated object that always lands before
LocalRefCount. It does seem a bit weird to be storing 1<<30 though --
there are no 1<<30 constants that we might be storing for examp
On 30 December 2012 02:45, Daniel Farina wrote:
> As I recall, the gist of this objection had to do with a false sense
> of stability of the hash value, and the desire to enforce the ability
> to alter it. Here's an option: xor the hash value with the
> 'statistics session id', so it's *known* to
On Sat, Dec 29, 2012 at 7:12 PM, Peter Geoghegan wrote:
> On 30 December 2012 02:45, Daniel Farina wrote:
>> As I recall, the gist of this objection had to do with a false sense
>> of stability of the hash value, and the desire to enforce the ability
>> to alter it. Here's an option: xor the has
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> On 30 December 2012 02:01, Stephen Frost wrote:
> > I really don't think what I sketched out or something similar would
> > happen. I do think it's incredibly frustrating as a user who is trying
> > to develop an application which behaves correct
On Wed, 2012-12-19 at 15:13 +, Albe Laurenz wrote:
> While playing with LDAP authentication, I discovered
> two documentation bugs.
>
> First, user and password for the first step in the
> two-step authentication mode are "ldapbinddn" and
> "ldapbindpasswd", not "ldapbinduser" and "ldapbinddn"
On Sat, 2012-12-29 at 08:11 -0500, Robert Haas wrote:
> On Tue, Dec 25, 2012 at 1:42 PM, Dimitri Fontaine
> wrote:
> > Robert Haas writes:
> >>> Also, keep in mind we want the ObjectID in all CREATE, ALTER and DROP
> >>> statements, so my current patch is still some bricks shy of a load… (I
> >>>
On 30 December 2012 03:32, Stephen Frost wrote:
> Err. I intended to say "I really don't think what I sketched out, or
> something similar, would be that unlikely to happen", or something along
> those lines. Apologies for the confusion.
Almost anything can be misused.
If you're going to insis
On Sat, Dec 29, 2012 at 10:07 PM, Greg Smith wrote:
> It is a strange power of two to be appearing there. I can follow your
> reasoning for why this could be a bit flipping error. There's no sign of
> that elsewhere though, no other crashes under load. I'm using this server
> here because it's
On 30 December 2012 04:37, Robert Haas wrote:
> On Sat, Dec 29, 2012 at 10:07 PM, Greg Smith wrote:
>> It is a strange power of two to be appearing there. I can follow your
>> reasoning for why this could be a bit flipping error. There's no sign of
>> that elsewhere though, no other crashes und
On Mon, Dec 24, 2012 at 10:43 AM, Charles Gomes wrote:
> And I had no performance improvements at all.
> Took the same time as with the previous EXECUTE statement;
>
> I don't see what am I doing wrong.
You might not be doing anything wrong. Triggers ARE slow.
If you have "perf" on your system,
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> On 30 December 2012 03:32, Stephen Frost wrote:
> > Err. I intended to say "I really don't think what I sketched out, or
> > something similar, would be that unlikely to happen", or something along
> > those lines. Apologies for the confusion.
>
On Sat, Dec 29, 2012 at 7:16 PM, Daniel Farina wrote:
> On Sat, Dec 29, 2012 at 7:12 PM, Peter Geoghegan
> wrote:
>> On 30 December 2012 02:45, Daniel Farina wrote:
>>> As I recall, the gist of this objection had to do with a false sense
>>> of stability of the hash value, and the desire to enf
2012/12/30 Stephen Frost :
> * Peter Geoghegan (pe...@2ndquadrant.com) wrote:
>> On 30 December 2012 03:32, Stephen Frost wrote:
>> > Err. I intended to say "I really don't think what I sketched out, or
>> > something similar, would be that unlikely to happen", or something along
>> > those lines
77 matches
Mail list logo
