Hello
2012/12/28 Heikki Linnakangas :
> On 28.12.2012 23:53, Peter Eisentraut wrote:
>>
>> On 12/27/12 1:07 AM, Pavel Stehule wrote:
>>>
>>> Hello
>>>
>>> I rechecked performance of dynamic SQL and it is significantly slower
>>> in 9.2 than 9.1
>>>
>>> -- 9.1
>>> postgres=# create or replace funct
2012/12/29 Tom Lane :
> Peter Eisentraut writes:
>> On 12/28/12 2:03 PM, Peter Geoghegan wrote:
>>> None of the Python built-in exception types have this kind of
>>> information available from fields or anything.
>
>> Sure, OSError has a filename attribute (which I'm sure is qualified by a
>> dire
On 12/29/2012 11:05 AM, Jaime Casanova wrote:
On Fri, Dec 28, 2012 at 8:36 PM, Vlad Arkhipov wrote:
Some use cases:
1. Complex rules in C language.
2. Transforming an original query into a series of queries. For example,
instead of UPDATE query on a table you may wish to execute UPDATE and INSE
On Fri, Dec 28, 2012 at 8:36 PM, Vlad Arkhipov wrote:
>
> Some use cases:
> 1. Complex rules in C language.
> 2. Transforming an original query into a series of queries. For example,
> instead of UPDATE query on a table you may wish to execute UPDATE and INSERT
> into *the same* table.
>
the seco
On 29 December 2012 01:36, Vlad Arkhipov wrote:
> Are there any plans on adding a rewriter hook?
I doubt it will ever happen.
If you look at QueryRewrite(Query *parsetree), the primary entry point
to the rewriter, it's easy enough to get a high level overview of what
goes on.
You can get the po
Hi all,
Are there any plans on adding a rewriter hook? There are already exist
parser, planner, executor hooks but there is no way to control rewriter
from plugins.
Some use cases:
1. Complex rules in C language.
2. Transforming an original query into a series of queries. For example,
instea
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 actually does is a separate
question.)
> Perhaps the parser could
Peter Eisentraut writes:
> On 12/28/12 2:03 PM, Peter Geoghegan wrote:
>> None of the Python built-in exception types have this kind of
>> information available from fields or anything.
> Sure, OSError has a filename attribute (which I'm sure is qualified by a
> directory name if necessary), Synt
While tuning an application, I found the posts from 2003 recomending the
use of LOWER() and LIKE in place of ILIKE to take advantage of indices.
For this app, given the limitations of the upper-layer protocol it must
support, that change replaced about 30 minutes of repeated seq scans with
about 1
On 28.12.2012 23:53, Peter Eisentraut wrote:
On 12/27/12 1:07 AM, Pavel Stehule wrote:
Hello
I rechecked performance of dynamic SQL and it is significantly slower
in 9.2 than 9.1
-- 9.1
postgres=# create or replace function test() returns void as $$ begin
for i in 1..100 loop execute 'sele
On 12/27/12 1:07 AM, Pavel Stehule wrote:
> Hello
>
> I rechecked performance of dynamic SQL and it is significantly slower
> in 9.2 than 9.1
>
> -- 9.1
> postgres=# create or replace function test() returns void as $$ begin
> for i in 1..100 loop execute 'select 1'; end loop; end $$ language
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 PostgreSQL syntax CALL ( B := 1, A := 2)
I agre
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 PostgreSQL syntax CALL ( B := 1, A := 2)
I agree it's probably time.
> * shou
On 12/28/12 7:09 AM, Hannu Krosing wrote:
> Maybe just export the function with the same name as is defined in
> CREATE FUNCTION ?
>
> And in case we do want to override it, call it
>
> CREATE FUNCTION foo(a int,b int, c text) AS $$
> # plpython: module modulename
> import x,y,z
>
> def foo(a,b,
On 28 December 2012 20:40, Peter Eisentraut wrote:
> Sure, OSError has a filename attribute (which I'm sure is qualified by a
> directory name if necessary), SyntaxError has filename, lineno, etc.
>
> OSError.filename is essentially the equivalent of what is being proposed
> here.
I disagree. Tha
2012/12/28 Peter Geoghegan :
> On 28 December 2012 20:40, Pavel Stehule wrote:
>> It cannot to wait to GET DIAGNOSTICS request - because when GET
>> DIAGNOSTICS is called, then all unsupported info about exception is
>> lost, all used memory will be released.
>
> I'm not suggesting that you do. I'
On 28 December 2012 20:40, Pavel Stehule wrote:
> It cannot to wait to GET DIAGNOSTICS request - because when GET
> DIAGNOSTICS is called, then all unsupported info about exception is
> lost, all used memory will be released.
I'm not suggesting that you do. I'm only suggesting that the two are
no
2012/12/28 Peter Geoghegan :
> On 28 December 2012 19:55, Pavel Stehule wrote:
>> http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Fdb2%2Frbafzmstgetdiag.htm
>
> I'm unconvinced by this. First of all, it only applies to the GET
> DIAGNOSTICS statement, and the only implement
On 28 December 2012 20:34, Peter Eisentraut wrote:
> Isn't that the whole point of this patch? The only purpose of this
> feature is to make the exception information available in a
> "machine-readable" way. That functionality has been requested many
> times over the years.
Right, and I agree t
On 12/28/12 2:03 PM, Peter Geoghegan wrote:
> Are you aware of any popular programming language that provides this
> kind of information? Can you tell in a well-principled way what
> function a Python exception originated from, for example? These are
> the built-in Python 2 exception classes:
>
>
On 28 December 2012 19:55, Pavel Stehule wrote:
> http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Fdb2%2Frbafzmstgetdiag.htm
I'm unconvinced by this. First of all, it only applies to the GET
DIAGNOSTICS statement, and the only implementation that actually
currently uses th
On 12/28/12 2:03 PM, Peter Geoghegan wrote:
> No, that's not what I mean. What I mean is that it seems questionable
> to want to do anything *within* an exception handler on the basis of
> where an exception was raised from.
Isn't that the whole point of this patch? The only purpose of this
featu
Hi Karl,
Sorry for the slow reply ...
Excerpt from Karl O. Pinc On Mon, Dec 10, 2012 at 5:00 AM:
> I was thinking along the same lines, that case 2) stderr to a file
> or pipe needs addressing. I think it's necessary to address the
> issue now. Otherwise we risk cluttering up the syntax in
>
On 12/10/12 4:23 PM, Peter Geoghegan wrote:
> Well, this is an area that the standard doesn't have anything to say
> about. The standard defines errcodes, but not what fields they make
> available. I suppose you could say that the patch proposes that they
> become a Postgres extension to the standa
2012/12/28 Peter Geoghegan :
> On 28 December 2012 19:23, Pavel Stehule wrote:
>> for this subject ANSI SQL is more relevant source or manual for DB2 or
>> Oracle. Design of Python and native PL languages are different. Python
>> can use complex nested structures. PL - PL/pgSQL or PL/PSM is design
On 28 December 2012 19:23, Pavel Stehule wrote:
> for this subject ANSI SQL is more relevant source or manual for DB2 or
> Oracle. Design of Python and native PL languages are different. Python
> can use complex nested structures. PL - PL/pgSQL or PL/PSM is designed
> for work with simply scalar t
2012/12/28 Peter Geoghegan :
> On 28 December 2012 18:40, Pavel Stehule wrote:
>> If
>> I understand you, we have a fields that has behave that you expected -
>> filename and funcname. And I have not used these fields for
>> application programming.
>
> No, that's not what I mean. What I mean is t
On 28 December 2012 18:40, Pavel Stehule wrote:
> If
> I understand you, we have a fields that has behave that you expected -
> filename and funcname. And I have not used these fields for
> application programming.
No, that's not what I mean. What I mean is that it seems questionable
to want to d
On 12/28/12 4:05 AM, Fabrízio de Royes Mello wrote:
Hi all,
And about proposal that originated this thread... I proposed only to add a
column on shared catalog "pg_database" with timestamp of its creation.
Event triggers don't cover "CREATE DATABASE" statement.
Works for me, in that case.
Yo
On 2012-12-28 14:59:50 -0300, Alvaro Herrera wrote:
> Andres Freund escribió:
> > On 2012-12-17 13:16:47 -0500, Tom Lane wrote:
> > > Andres Freund writes:
> > > > On 2012-12-17 12:47:41 -0500, Tom Lane wrote:
> > > >> But, if the day ever comes when 64 bits doesn't seem like enough, I bet
> > > >
On 12/28/2012 09:15 AM, Peter Eisentraut wrote:
On Mon, 2012-12-17 at 16:34 -0500, Peter Eisentraut wrote:
Yes, this would be a good solution for some applications, but the only
way I can think of to manage the compatibility issue is to invent some
function attribute system like
CREATE FUNCTION
On Thu, Dec 27, 2012 at 5:39 PM, Peter Bex wrote:
> On Thu, Dec 27, 2012 at 12:31:08PM -0300, Claudio Freire wrote:
>> On Thu, Dec 27, 2012 at 11:46 AM, Peter Bex wrote:
>> >
>> > Implementing a more secure challenge-response based algorithm means
>> > a change in the client-server protocol. Per
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 worth
> the compatibility hit of changing the CSV column se
On 28 December 2012 14:00, Stephen Frost wrote:
> There are some additional concerns regarding the patch itself that I
> have (do we really want to modify ereport() in this way? How can we
> implement something which scales better than just adding more and more
> parameters?) but I think we need
I'm creating a simple trigger that will be called during an insert and change
the destination table.
All values are going to be preserved, just the destination table will be
different.
From what I see I can't modify trigdata->tg_relation.
All examples use: return Datum(trigdata->tg_trigtuple);
Andres Freund escribió:
> On 2012-12-17 13:16:47 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2012-12-17 12:47:41 -0500, Tom Lane wrote:
> > >> But, if the day ever comes when 64 bits doesn't seem like enough, I bet
> > >> we'd move to 128-bit integers, which will surely be available
On 28 December 2012 11:43, Daniel Farina wrote:
> Without further ado, the cover letter taken from the top of the patch:
>
> This tries to establish a maximum under-estimate of the number of
> calls for a given pg_stat_statements entry. That means the number of
> calls to the canonical form of th
Hello
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 PostgreSQL syntax CALL ( B := 1, A := 2)
Patch is very simple, but there are lot of questions about support
previous syntax.
* sh
Stephen Frost writes:
> To be honest, I haven't been following this thread at all, but I'm kind
> of amazed that this patch seems to be progressing. I spent quite a bit
> of time previously trying to change the CSV log structure to add a
> single column and this patch is adding a whole slew of th
Hi,
Today, I tried to make fun with the new background worker processes in
9.3, but I found something disturbing, and need help to go further.
My code is available on https://github.com/gleu/stats_recorder. If you
take a look, it is basically a copy of Alvarro's worker_spi contrib
module with a f
> On 12/28/2012 09:15 AM, Peter Eisentraut wrote:
>> An alternative that has some amount of precedent in the Python world
>> would be to use comment pragmas, like this: ...
>> This way we could get this done fairly easily without any new
>> infrastructure outside the language handler.
+1 for not c
Peter Eisentraut writes:
> SPI was invented before there was proper exception handling, so it
> communicates errors by return values. This makes programming with SPI
> either prone to errors of omission, or very ugly (ultimately, the
> standard reasons why exceptions were invented).
> So I was p
On 12/28/2012 03:15 AM, Peter Eisentraut wrote:
On Mon, 2012-12-17 at 16:34 -0500, Peter Eisentraut wrote:
Yes, this would be a good solution for some applications, but the only
way I can think of to manage the compatibility issue is to invent some
function attribute system like
CREATE FUNCTIO
Hello
2012/12/28 Stephen Frost :
> Pavel, Peter,
>
> To be honest, I haven't been following this thread at all, but I'm kind
> of amazed that this patch seems to be progressing. I spent quite a bit
> of time previously trying to change the CSV log structure to add a
> single column and this patch
Pavel, Peter,
To be honest, I haven't been following this thread at all, but I'm kind
of amazed that this patch seems to be progressing. I spent quite a bit
of time previously trying to change the CSV log structure to add a
single column and this patch is adding a whole slew of them. My prior
pa
On 12/28/2012 09:15 AM, Peter Eisentraut wrote:
On Mon, 2012-12-17 at 16:34 -0500, Peter Eisentraut wrote:
Yes, this would be a good solution for some applications, but the only
way I can think of to manage the compatibility issue is to invent some
function attribute system like
CREATE FUNCTION
Hi all,
And about proposal that originated this thread... I proposed only to add a
column on shared catalog "pg_database" with timestamp of its creation.
Event triggers don't cover "CREATE DATABASE" statement.
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Blog sobre TI
On 28 December 2012 11:27, Amit Kapila wrote:
>> * TOAST is not handled at all. No comments about it, nothing. Does
>> that mean it hasn't been considered? Or did we decide not to care in
>> this release?
>
>> Presumably that means we are comparing toast pointers
>> byte by byte to see if they ar
On 28 December 2012 11:27, Amit Kapila wrote:
>> * The internal docs are completely absent. We need at least a whole
>> page of descriptive comment, discussing trade-offs and design
>> decisions. This is very important because it will help locate bugs
>> much faster if these things are clealry do
Hello,
After long delay (sorry) here's a patch implementing what was
hand-waved at in
http://archives.postgresql.org/pgsql-hackers/2012-10/msg00176.php
I am still something at a loss at how to test it besides prodding it
by hand; it seems like it's going to involve infrastructure or
introducing h
On Friday, December 28, 2012 1:38 PM Kyotaro HORIGUCHI wrote:
> Hello, I saw this patch and confirmed that
>
> - Coding style looks good.
> - Appliable onto HEAD.
> - Some mis-codings are fixed.
>
> And took the performance figures for 4 types of modification versus 2
> benchmarks.
>
> As a w
On Friday, December 28, 2012 3:52 PM Simon Riggs wrote:
> On 28 December 2012 08:07, Kyotaro HORIGUCHI
> wrote:
>
> > Hello, I saw this patch and confirmed that
> >
> > - Coding style looks good.
> > - Appliable onto HEAD.
> > - Some mis-codings are fixed.
>
> I've had a quick review of the p
On 28 December 2012 08:07, Kyotaro HORIGUCHI
wrote:
> Hello, I saw this patch and confirmed that
>
> - Coding style looks good.
> - Appliable onto HEAD.
> - Some mis-codings are fixed.
I've had a quick review of the patch to see how close we're getting.
The perf tests look to me like we're ge
Stephen Frost writes:
> Apparently I've managed to miss the tricky case..?
That shouldn't be tricky as a user, but has been a tricky subject every
time we've been talking about implement Event Triggers in the past two
years, so I though I would include it:
create schema test
create ta
2012/12/28 Peter Eisentraut :
> On Mon, 2012-12-17 at 16:34 -0500, Peter Eisentraut wrote:
>> Yes, this would be a good solution for some applications, but the only
>> way I can think of to manage the compatibility issue is to invent some
>> function attribute system like
>>
>> CREATE FUNCTION ...
On Mon, 2012-12-17 at 16:34 -0500, Peter Eisentraut wrote:
> Yes, this would be a good solution for some applications, but the only
> way I can think of to manage the compatibility issue is to invent some
> function attribute system like
>
> CREATE FUNCTION ... OPTIONS (call_convention 'xyz')
An
SPI was invented before there was proper exception handling, so it
communicates errors by return values. This makes programming with SPI
either prone to errors of omission, or very ugly (ultimately, the
standard reasons why exceptions were invented).
So I was pondering whether we could introduce
57 matches
Mail list logo
