2012/12/28 Gavin Flower gavinflo...@archidevsys.co.nz:
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)
TL == Tom Lane t...@sss.pgh.pa.us 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
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 pe...@2ndquadrant.com wrote:
However, with this approach, calls_underest
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
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: last
On Tue, Dec 25, 2012 at 10:34 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr 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
On Sat, Dec 29, 2012 at 4:21 AM, Daniel Farina drfar...@acm.org 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
On Tue, Dec 25, 2012 at 1:42 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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 +++-
On Fri, Dec 28, 2012 at 11:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
James Cloos cl...@jhcloos.com 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.
Fabrízio de Royes Mello fabriziome...@gmail.com 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
On Sat, Dec 29, 2012 at 2:05 PM, Greg Stark st...@mit.edu 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
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
Stephen Frost sfr...@snowman.net 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
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
* 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 for
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 be to
* 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 another
On 29 December 2012 05:04, Pavel Stehule pavel.steh...@gmail.com 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
Andres Freund and...@2ndquadrant.com 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
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 robertmh...@gmail.com 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
Peter Geoghegan pe...@2ndquadrant.com writes:
On 29 December 2012 05:04, Pavel Stehule pavel.steh...@gmail.com 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
2012/12/29 Peter Geoghegan pe...@2ndquadrant.com:
On 29 December 2012 05:04, Pavel Stehule pavel.steh...@gmail.com 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
2012/12/29 Tom Lane t...@sss.pgh.pa.us:
Peter Geoghegan pe...@2ndquadrant.com writes:
On 29 December 2012 05:04, Pavel Stehule pavel.steh...@gmail.com 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
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
On 28 December 2012 15:57, Tom Lane t...@sss.pgh.pa.us 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
On 29 December 2012 17:43, Stephen Frost sfr...@snowman.net 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
2012/12/29 Peter Geoghegan pe...@2ndquadrant.com:
On 29 December 2012 17:43, Stephen Frost sfr...@snowman.net 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
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
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 bytes
Hello
2012/12/29 Stephen Frost sfr...@snowman.net:
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
* 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 with
On 30/12/12 05:24, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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.
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
2012/12/29 Stephen Frost sfr...@snowman.net:
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
* 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 complicate an
2012/12/29 Stephen Frost sfr...@snowman.net:
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
2012/12/29 Stephen Frost sfr...@snowman.net:
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
Pavan,
* Pavan Deolasee (pavan.deola...@gmail.com) wrote:
On Tue, Dec 4, 2012 at 6:01 PM, Pavan Deolasee
pavan.deola...@gmail.comwrote:
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
On 29 December 2012 18:37, Stephen Frost sfr...@snowman.net 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
* 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 pe...@2ndquadrant.com:
On 29 December 2012 18:37, Stephen Frost sfr...@snowman.net 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
* 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
2012/12/29 Stephen Frost sfr...@snowman.net:
* 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
* 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? Using
2012/12/29 Stephen Frost sfr...@snowman.net:
* 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
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:
I
On 29 December 2012 19:56, Stephen Frost sfr...@snowman.net 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
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 psql
* 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
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 Riggssi...@2ndquadrant.com 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
2012/12/29 Stephen Frost sfr...@snowman.net:
* 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
* 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 sfr...@snowman.net:
* 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
On 29 December 2012 20:49, Stephen Frost sfr...@snowman.net 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
On 29 December 2012 21:24, Pavel Stehule pavel.steh...@gmail.com 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
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 don't
On 29 December 2012 22:57, Stephen Frost sfr...@snowman.net 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
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 with
On 29 December 2012 12:21, Daniel Farina drfar...@acm.org 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
On Sat, Dec 29, 2012 at 6:37 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 29 December 2012 12:21, Daniel Farina drfar...@acm.org 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
On Thu, Dec 27, 2012 at 11:33 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@mit.edu writes:
On Thu, Dec 27, 2012 at 3:17 AM, Tom Lane t...@sss.pgh.pa.us 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
On 30 December 2012 02:01, Stephen Frost sfr...@snowman.net 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
On Sun, Dec 23, 2012 at 8:41 PM, Tomas Vondra t...@fuzzy.cz 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
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 130 though --
there are no 130 constants that we might be storing for example.
On 30 December 2012 02:45, Daniel Farina dan...@heroku.com 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
On Sat, Dec 29, 2012 at 7:12 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 30 December 2012 02:45, Daniel Farina dan...@heroku.com 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
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
On 30 December 2012 02:01, Stephen Frost sfr...@snowman.net 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
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.
This bug
On Sat, 2012-12-29 at 08:11 -0500, Robert Haas wrote:
On Tue, Dec 25, 2012 at 1:42 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
Also, keep in mind we want the ObjectID in all CREATE, ALTER and DROP
statements, so my current patch is still
On 30 December 2012 03:32, Stephen Frost sfr...@snowman.net 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
On Sat, Dec 29, 2012 at 10:07 PM, Greg Smith g...@2ndquadrant.com 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
On 30 December 2012 04:37, Robert Haas robertmh...@gmail.com wrote:
On Sat, Dec 29, 2012 at 10:07 PM, Greg Smith g...@2ndquadrant.com 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
On Mon, Dec 24, 2012 at 10:43 AM, Charles Gomes charle...@outlook.com 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
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
On 30 December 2012 03:32, Stephen Frost sfr...@snowman.net 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
On Sat, Dec 29, 2012 at 7:16 PM, Daniel Farina dan...@heroku.com wrote:
On Sat, Dec 29, 2012 at 7:12 PM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
On 30 December 2012 02:45, Daniel Farina dan...@heroku.com wrote:
As I recall, the gist of this objection had to do with a false sense
of
2012/12/30 Stephen Frost sfr...@snowman.net:
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
On 30 December 2012 03:32, Stephen Frost sfr...@snowman.net 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
77 matches
Mail list logo
