On Sat, Apr 11, 2009 at 03:48:33PM +0900, Hitoshi Harada wrote:
> 2009/4/11 Andrew Gierth :
> >> "Tom" == Tom Lane writes:
> >
> > >>> Perhaps more to the point: the previous round of discussion about
> > >>> this already rejected the idea of treating window functions as a
> > >>> category
2009/4/11 Tom Lane :
> Bruce Momjian writes:
>> Yea, I thought we were going to do this:
>
>> Please find enclosed one way to handle it, this being prepending
>> WINDOW to the result types in \df.
>
>> but I don't see this behavior in CVS.
>
> IIRC, my original proposal involved adding something t
2009/4/11 Andrew Gierth :
>> "Tom" == Tom Lane writes:
>
> >>> Perhaps more to the point: the previous round of discussion about
> >>> this already rejected the idea of treating window functions as a
> >>> category fundamentally separate from plain functions --- that is,
> >>> we are not f
On Fri, Apr 10, 2009 at 11:47 PM, Abhijit Menon-Sen wrote:
> Hi.
>
> There's a TODO item about making COMMENT ON accept an expression.
really? what's the use case for that?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
> "Tom" == Tom Lane writes:
>>> Perhaps more to the point: the previous round of discussion about
>>> this already rejected the idea of treating window functions as a
>>> category fundamentally separate from plain functions --- that is,
>>> we are not following the "aggregate" model of ha
Hi.
There's a TODO item about making COMMENT ON accept an expression. The
grammar change is simple (SConst|NULL_P->a_expr), but as far as I can
see, there are no similar utility commands that take expressions, and
I'm not very familiar with the planner and executor, so I could use
some advice abou
Andrew Dunstan writes:
> Tom Lane wrote:
>> ... Seems like it's nearly a one-liner fix, too.
> Well, what I have in mind is a bit bigger, but not large. See attached
> patch.
Hmm, you do need two instances of the loop, don't you? Might be
better to refactor along the lines of
if (has
> -Original Message-
> From: Dave Page [mailto:dp...@pgadmin.org]
> Sent: Friday, April 10, 2009 1:58 PM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org; Bill Luton; Larry McGhaw; Mike
McKee;
> Brian Fifer
> Subject: Re: [HACKERS] Windows installation service
>
> On Fri, Apr 10, 2009
Adnrew,
Well, what I have in mind is a bit bigger, but not large. See attached
patch.
I'll test it this weekend.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.pos
Tom Lane wrote:
Andrew Dunstan writes:
What you're missing is that we need to compare the lockdeps of each item
(i.e. both the candidate item and the running item) with all the deps
(not just the lockdeps) of the other item. If neither item has any
lockdeps there will be no conflict. Thi
Andrew Dunstan writes:
> What you're missing is that we need to compare the lockdeps of each item
> (i.e. both the candidate item and the running item) with all the deps
> (not just the lockdeps) of the other item. If neither item has any
> lockdeps there will be no conflict. This will allow co
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
Doesn't that eliminate any chance of running two CREATE INDEXes
concurrently on the same table?
No, since neither of them will have any locking dependencies, which are
only for items that take an exclusive lock on th
Andrew Dunstan writes:
> Tom Lane wrote:
>> Doesn't that eliminate any chance of running two CREATE INDEXes
>> concurrently on the same table?
> No, since neither of them will have any locking dependencies, which are
> only for items that take an exclusive lock on the table(s), such as FK
> con
So I started to look at what might be involved in teaching plpgsql about
standard_conforming_strings, and was soon dismayed by the sheer epic
nature of its failure to act like the core lexer. It was shaky enough
before, but the recent introduction of Unicode strings and identifiers
into the core h
"David E. Wheeler" writes:
> On Apr 10, 2009, at 12:15 PM, Tom Lane wrote:
>> I gave my reasoning before: widening this API has possibly nontrivial
>> future maintenance costs, and the actual use-case for the data is
>> unconvincing.
> It seems to me that the immediate patch to simply copy zone.t
Tom Lane wrote:
Andrew Dunstan writes:
Yeah. I think the correct logic is roughly this: When considering if a
candidate item has a locking conflict with a running item, then if
*either* of them has a locking dependency that coincides with *any*
dependency of the other item, then the cand
Andrew Dunstan writes:
> Yeah. I think the correct logic is roughly this: When considering if a
> candidate item has a locking conflict with a running item, then if
> *either* of them has a locking dependency that coincides with *any*
> dependency of the other item, then the candidate is reject
"Kevin Grittner" writes:
> Well, that's a change I'm arguing for. That would require both the
> plpgsql parser change Tom is talking about, and a change to CREATE
> FUNCTION such that there is an implied SET standard_compliant_strings
> FROM CURRENT -- which is something I've suggested a couple t
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Back to the point at hand: do we want to look at making plpgsql
> Tom> respect the GUC?
> Surely what matters is the value of the GUC at the time that you did
> the CREATE FUNCTION, not the value at the time you happen to be
> calling it
On Fri, Apr 10, 2009 at 8:29 PM, Dann Corbit wrote:
> I don't know the reason why, but that is not what happens here.
>
> We see the problem on 64-bit machines with Windows 2008 Server.
> We see the problem on 32-bit machine with Windows 2003 Server.
> We see the problem on 32-bit Windows XP mach
Josh Berkus wrote:
Tom, Andrew,
Well, we certainly want to be able to run CREATE INDEXes in parallel,
so this would appear to require hard-wiring some conception of shared
versus exclusive lock into pg_restore. I think it might be a bit late
to consider that for 8.4.
I'm pretty sure I had
l0rins writes:
> In version 8.1, tsearch2.sql contained SQL statements to create 4 pg_ts_*
> tables: pg_ts_cfg, pg_ts_dict, ... and populate them with data. These
> statements are missing in tsearch2.sql 8.3.7 version. So, I'm getting:
> ERROR: relation "pg_ts_*" does not exist when trying to
Andrew Gierth wrote:
> Surely what matters is the value of the GUC at the time that you did
> the CREATE FUNCTION, not the value at the time you happen to be
> calling it?
Well, that's a change I'm arguing for. That would require both the
plpgsql parser change Tom is talking about, and a chang
> "Tom" == Tom Lane writes:
Tom> Back to the point at hand: do we want to look at making plpgsql
Tom> respect the GUC?
Surely what matters is the value of the GUC at the time that you did
the CREATE FUNCTION, not the value at the time you happen to be
calling it?
--
Andrew (irc:RhodiumTo
Tom,
Actually, what this thread is leading me towards is the idea that almost
nobody really has standard_conforming_strings turned on in production
(except maybe with apps ported from Oracle or someplace else). If they
did, we'd be seeing more complaints about plpgsql not working properly.
So m
On Apr 10, 2009, at 12:15 PM, Tom Lane wrote:
I gave my reasoning before: widening this API has possibly nontrivial
future maintenance costs, and the actual use-case for the data is
unconvincing.
It seems to me that the immediate patch to simply copy zone.tab has no
effect on the API. That's
Tom Lane wrote:
> do we want to look at making plpgsql respect the GUC?
+1
> I'm inclined to deal with the special case (RAISE and anything else
> similar) by changing the code so that we *do* feed the string
> literal through the main parser, not for any functional effect but
> just to have
Tom, Andrew,
Well, we certainly want to be able to run CREATE INDEXes in parallel,
so this would appear to require hard-wiring some conception of shared
versus exclusive lock into pg_restore. I think it might be a bit late
to consider that for 8.4.
I'm pretty sure I had the logic for this co
Bruce Momjian writes:
> Kevin Grittner wrote:
>> My personal bias is to go to the standard behavior as the default at
>> some point. For legacy reasons, I don't know that you would ever want
>> to remove the setting; especially since I don't think it adds much
>> code if you're going to support t
Kevin Grittner wrote:
> Bruce Momjian wrote:
> > It would be nice to know if we are ever going to set
> > standard_conforming_strings to on.
>
> My personal bias is to go to the standard behavior as the default at
> some point. For legacy reasons, I don't know that you would ever want
> to remo
Bruce Momjian wrote:
> It would be nice to know if we are ever going to set
> standard_conforming_strings to on.
My personal bias is to go to the standard behavior as the default at
some point. For legacy reasons, I don't know that you would ever want
to remove the setting; especially since I d
>Surely we'd have seen more complaints, then.
> regards, tom lane
This gets a definite +1 here as we are using "SET TIMEZONE" at the
beginning of each transaction so that each user sees/records dates
automatically in whatever timezone they have associated with them.
Works bea
Tom Lane wrote:
> "Kevin Grittner" writes:
> > Let me ask this -- If we were to change the plpgsql parser to pay
> > attention to the GUC, it couldn't break anything for any environment
> > which always has the GUC 'off', could it?
>
> Right, because the behavior wouldn't actually change.
>
> I'
> -Original Message-
> From: Dann Corbit
> Sent: Friday, April 10, 2009 12:30 PM
> To: 'Dave Page'
> Cc: pgsql-hackers@postgresql.org; Bill Luton; Larry McGhaw; Mike McKee;
> Brian Fifer
> Subject: RE: [HACKERS] Windows installation service
>
> > -Original Message-
> > From: Dave P
> -Original Message-
> From: Dave Page [mailto:dp...@pgadmin.org]
> Sent: Friday, April 10, 2009 8:16 AM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org; Bill Luton; Larry McGhaw; Mike McKee;
> Brian Fifer
> Subject: Re: [HACKERS] Windows installation service
>
> On Mon, Apr 6, 2009 a
"Kevin Grittner" writes:
> Let me ask this -- If we were to change the plpgsql parser to pay
> attention to the GUC, it couldn't break anything for any environment
> which always has the GUC 'off', could it?
Right, because the behavior wouldn't actually change.
I'm starting to lean in the same d
Bruce Momjian writes:
> Brendan Jurd wrote:
>> I agree that there are probably a great many app authors out there who
>> don't realise how very boned they might be if the default GUC gets
>> changed and they haven't prepared their SQL to cope.
> I assume those authors are getting warnings, which
On Fri, Apr 10, 2009 at 3:01 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Tom,
>>> Like what? I do not actually believe that anyone needs an
>>> interactive geographical timezone selector based on
>>> pg_timezone_names.
>
>> Actually, considering that PostgreSQL is the leading open source GIS
>>
Tom Lane wrote:
> "Kevin Grittner" writes:
>> The aspect of 8.3 behavior that concerns me most is that neither
>> the author of a function, nor anyone using it, can control or
>> predict which way a string literal with a backslash will be
>> interpreted, unless the author explicitly specifies th
David Fetter writes:
> You're setting a pretty high bar here for a pretty small change which
> will cause a pretty large increase in convenience. What is the actual
> problem here?
I gave my reasoning before: widening this API has possibly nontrivial
future maintenance costs, and the actual use-
Brendan Jurd wrote:
> On Sat, Apr 11, 2009 at 4:40 AM, Kevin Grittner
> wrote:
> > The aspect of 8.3 behavior that concerns me most is that neither the
> > author of a function, nor anyone using it, can control or predict
> > which way a string literal with a backslash will be interpreted,
> > unl
On Fri, Apr 10, 2009 at 03:01:05PM -0400, Tom Lane wrote:
> Josh Berkus writes:
> > Tom,
> >> Like what? I do not actually believe that anyone needs an
> >> interactive geographical timezone selector based on
> >> pg_timezone_names.
>
> > Actually, considering that PostgreSQL is the leading open
On Sat, Apr 11, 2009 at 4:40 AM, Kevin Grittner
wrote:
> The aspect of 8.3 behavior that concerns me most is that neither the
> author of a function, nor anyone using it, can control or predict
> which way a string literal with a backslash will be interpreted,
> unless the author explicitly specif
Josh Berkus writes:
> Tom,
>> Like what? I do not actually believe that anyone needs an
>> interactive geographical timezone selector based on
>> pg_timezone_names.
> Actually, considering that PostgreSQL is the leading open source GIS
> database, I expect that a *lot* of people want this.
Sur
"Kevin Grittner" writes:
> The aspect of 8.3 behavior that concerns me most is that neither the
> author of a function, nor anyone using it, can control or predict
> which way a string literal with a backslash will be interpreted,
> unless the author explicitly specifies the SET
> standard_conform
Tom Lane wrote:
>> Can you show one case where having plgpsql parse the function body
>> based on the standard_conforming_strings GUC would break *anything*
>> that now works?
>
> regression=# create function foo() returns int as $$
> regression$# begin
> regression$# raise notice 'foo\'s bar'
"Kevin Grittner" writes:
> Tom Lane wrote:
>> I think you are confusing parsing of the string literal that
>> is the argument of CREATE FUNCTION with the parsing that the plpgsql
>> interpreter does on the function body once it gets it.
> Oh, I'm not confused about that at all. I'm arguing th
Hi,
I know very well, so all texts in my patches should be translated to
English. My language skills are really minimal.
So, please, if you can, propose these error messages (with hints)-
result will be much better.
Thank you
Pavel
2009/4/10 Brendan Jurd :
> On Sat, Apr 11, 2009 at 2:16 AM, Pa
On Sat, Apr 11, 2009 at 2:16 AM, Pavel Stehule wrote:
>
> I was surprised so PostgreSQL doesn't support this basic output format.
>
Hi Pavel,
I had a look through your patch and would like to suggest improvements
to the new error messages you've introduced.
1. "invalid using of format "
Th
Tom Lane escreveu:
Bruce Momjian writes:
Yea, I thought we were going to do this:
Please find enclosed one way to handle it, this being prepending
WINDOW to the result types in \df.
but I don't see this behavior in CVS.
IIRC, my original proposal involved adding something to the argumen
Fujii-san,
I like the new patch using the content of the file to determine the
mode. Much easier to use at failover time.
On Fri, 2009-04-10 at 12:47 +0900, Fujii Masao wrote:
> > One problem with this patch is that in smart mode, the trigger file is not
> > deleted. That's different from curre
Hello
I was surprised so PostgreSQL doesn't support this basic output format.
Regards
Pavel Stehule
*** ./src/backend/utils/adt/formatting.c.orig 2009-04-10 11:31:17.0 +0200
--- ./src/backend/utils/adt/formatting.c 2009-04-10 18:05:14.0 +0200
***
*** 335,340
--- 3
David Fetter writes:
> On Fri, Apr 10, 2009 at 11:30:30AM -0400, Tom Lane wrote:
>> Perhaps more to the point: the previous round of discussion about
>> this already rejected the idea of treating window functions as a
>> category fundamentally separate from plain functions --- that is, we
>> are n
Dann Corbit wrote:
The Windows installation service uses pg_ctl to perform the network
start-up operation.
This program starts up the postmaster and exits.
The net effect of performing the operation in this manner is that the
Windows service manager sees the service as "not running" a few minut
Tom Lane wrote:
Andrew Dunstan writes:
We still have a little work to do on dependencies in parallel
pg_restore. The current test compares the candidate's locking
dependencies with those of the running jobs, and allows the candidate is
there isn't a match. That's not a broad enough test.
On Fri, Apr 10, 2009 at 11:30:30AM -0400, Tom Lane wrote:
> David Fetter writes:
> > Revised patch attached. \dw does not need an 'S' decorator,
>
> Yes it does. We have only painfully gotten to the point of having
> consistent behavior across all the \d commands. We are not going to
> break t
Bruce Momjian writes:
> Yea, I thought we were going to do this:
> Please find enclosed one way to handle it, this being prepending
> WINDOW to the result types in \df.
> but I don't see this behavior in CVS.
IIRC, my original proposal involved adding something to the argument
list --- it seems
Tom Lane wrote:
> David Fetter writes:
> > Revised patch attached. \dw does not need an 'S' decorator,
>
> Yes it does. We have only painfully gotten to the point of having
> consistent behavior across all the \d commands. We are not going
> to break that consistency before it's even shipped.
l0rins writes:
> In version 8.1, tsearch2.sql contained SQL statements to create 4 pg_ts_*
> tables: pg_ts_cfg, pg_ts_dict, ... and populate them with data. These
> statements are missing in tsearch2.sql 8.3.7 version. So, I'm getting:
> ERROR: relation "pg_ts_*" does not exist when trying to run
David Fetter writes:
> Revised patch attached. \dw does not need an 'S' decorator,
Yes it does. We have only painfully gotten to the point of having
consistent behavior across all the \d commands. We are not going
to break that consistency before it's even shipped.
Perhaps more to the point:
On Tue, Apr 07, 2009 at 07:28:25PM -0700, David Fetter wrote:
> On Mon, Apr 06, 2009 at 10:51:22PM -0700, David Fetter wrote:
> > On Sun, Apr 05, 2009 at 05:57:46PM -0700, David Fetter wrote:
> > > On Sun, Apr 05, 2009 at 08:55:07PM -0400, Tom Lane wrote:
> > > > David Fetter writes:
> > > > > On
Dann Corbit wrote:
> > -Original Message-
> > From: Dann Corbit
> > Sent: Monday, March 23, 2009 3:50 PM
> > To: pgsql-gene...@postgresql.org
> > Subject: Multiple character encodings within a single database/table?
> >
> > If I have the C locale, can I have multiple character encodings
>
On Mon, Apr 6, 2009 at 9:32 PM, Dann Corbit wrote:
> The Windows installation service uses pg_ctl to perform the network
> start-up operation.
> This program starts up the postmaster and exits.
> The net effect of performing the operation in this manner is that the
> Windows service manager sees t
Michael Renner wrote:
> Bruce Momjian wrote:
> > Michael Renner wrote:
> >> Hi,
> >>
> >> this is a small update to the first paragraph of the WAL configuration
> >> chapter, going into more detail WRT redo vs. checkpoint records, since
> >> the underlying behavior is currently only deducible fro
On Fri, Mar 27, 2009 at 12:47 AM, Dann Corbit wrote:
> 64 bit Windows platform.
> PG Installer version, installed first, was 8.3.5
> EnterpriseDB version was 8.3.7
> There was an error message (file in use) during installation of the
> second tool set.
>
> It is also possible that it was caused b
Hello,
I'm trying to install tsearch2 on PostgreSQL 8.3.7 but I'm struggling to get
it run. I installed it successfully on PostgreSQL 8.1 but can't get it
working on 8.3.7 using the same steps. The steps I'm using are:
1. yum install postgresql-contrib
2. psql mydb < tsearch2.sql
In version 8.1
The Windows installation service uses pg_ctl to perform the network
start-up operation.
This program starts up the postmaster and exits.
The net effect of performing the operation in this manner is that the
Windows service manager sees the service as "not running" a few minutes
after the startup is
> -Original Message-
> From: Dann Corbit
> Sent: Monday, March 23, 2009 3:50 PM
> To: pgsql-gene...@postgresql.org
> Subject: Multiple character encodings within a single database/table?
>
> If I have the C locale, can I have multiple character encodings
within:
> 1. A single database?
>
If you install with the PostgreSQL group's installer for Windows:
http://www.postgresql.org/ftp/binary
And then install a second instance of PostgreSQL using the EnterpriseDB
one click installer:
http://www.enterprisedb.com/products/pgdownload.do#windows
An error may occur. It will occur, probab
Bruce Momjian wrote:
Michael Renner wrote:
Hi,
this is a small update to the first paragraph of the WAL configuration
chapter, going into more detail WRT redo vs. checkpoint records, since
the underlying behavior is currently only deducible from the source. I'm
not perfectly sure if I got ev
Andrew Dunstan writes:
> We still have a little work to do on dependencies in parallel
> pg_restore. The current test compares the candidate's locking
> dependencies with those of the running jobs, and allows the candidate is
> there isn't a match. That's not a broad enough test. The candidate
On Fri, Apr 10, 2009 at 5:47 AM, Fujii Masao wrote:
> One idea to solve this problem is to tell pg_standby as a
> command-line argument about whether the trigger file can be
> removed. That parameter value can be set to 'true' when the last
> applied record is re-fetched. Though pg_standby is call
72 matches
Mail list logo
