Gokulakannan Somasundaram wrote:
> Hmmm no-one else feels this as a bug
>
> The logic is that a function call is made for "similar" and the position
> where SIMILAR occurs is at the third position, but it has been coded that it
> is at fifth position.
The function call is constructed for
Hmmm no-one else feels this as a bug
The logic is that a function call is made for "similar" and the position
where SIMILAR occurs is at the third position, but it has been coded that it
is at fifth position.
Thanks,
Gokul.
On Tue, Oct 27, 2009 at 6:51 AM, Gokulakannan Somasundaram <
gok
On Mon, Nov 2, 2009 at 12:40 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>
>> I don't see anything in this code that is very rel-specific, so I
>> think it would be possible to implement spcoptions by just defining
>> RELOPT_KIND_TABLESPACE and ignoring the irony, but that has enough of
>> a
On Mon, Nov 2, 2009 at 4:11 PM, Dimitri Fontaine wrote:
> Hi, excuse the quoting style... and the intrepid nature of the following
> content...
>
> --
> dim
>
> Le 1 nov. 2009 à 13:43, Greg Stark a écrit :
>>
>> We could have a column for all booleans, a column for all integers,
>> etc. but that'
Dimitri Fontaine escribió:
> Thé other day, on IRC, someone wanted a dynamic table accepting
> value in whichever column you name. That would probably mean having
> a special INSERT INTO which ALTER TABLE ... ADD COLUMN ... for you.
That sounds more like something you'd do with hstore or somethin
Hi, excuse the quoting style... and the intrepid nature of the
following content...
--
dim
Le 1 nov. 2009 à 13:43, Greg Stark a écrit :
We could have a column for all booleans, a column for all integers,
etc. but that's not really any more normalized than having a single
column for all the t
Robert Haas writes:
> On Mon, Nov 2, 2009 at 11:31 AM, Tom Lane wrote:
>> Another interesting property
>> of this approach is that it'd fix the longstanding user complaint
>> that constructions like
>>if (TG_OP = 'INSERT' and NEW.foo = 'bar') ...
>> fail prematurely. The executor would
Magnus Hagander writes:
> On Mon, Nov 2, 2009 at 18:54, Tom Lane wrote:
>> [ rename some conversion libraries to shorten source path names ]
> Seems like this would be a major PITA for packagers and end-user.
If we actually wanted to back-patch it, I think the least painful way
would be to twea
2009/11/2 Tom Lane :
> Pavel Stehule writes:
>> 2009/11/2 Tom Lane :
>>> This kinda calls into question whether the Oracle way is actually
>>> a good idea or not; but my purpose here is not to debate that,
>>> just to look at what it takes to implement it.
>
>> This is reason, why I would to see t
Pavel Stehule writes:
> 2009/11/2 Tom Lane :
>> This kinda calls into question whether the Oracle way is actually
>> a good idea or not; but my purpose here is not to debate that,
>> just to look at what it takes to implement it.
> This is reason, why I would to see third mode (incompatible with
2009/11/2 Tom Lane :
> One of the interesting properties of Oracle-compatible variable
> references in plpgsql is that the set of variables referenced by a
> given query could change during a forced replan. For example,
> consider
>
> declare x int;
> r record;
> ...
>
On Mon, Nov 2, 2009 at 18:54, Tom Lane wrote:
> Steve Atkins writes:
>> I've also seen it with winzip. Again, ISTR that the exact limits were
>> obscure but that restricting the path to less than 100 characters
>> avoided any problems.
>
> Hmm. It strikes me that the names seen by tar include "p
On Mon, 2009-11-02 at 13:12 -0500, Tom Lane wrote:
> Jeff Davis writes:
> > On Mon, 2009-11-02 at 08:25 +, Peter Eisentraut wrote:
> >> I think the word CHECK should be avoided completely in this syntax, to
> >> avoid confusion with CHECK constraints.
>
> > This is an easy change. I don't hav
Euler Taveira de Oliveira wrote:
> Fujii Masao escreveu:
>> IMO, walreceiver should be a subprocess of postmaster for
>> the following reasons.
>>
> +1. I agree that the first version should be as close as possible to
> postmaster. My points are: (i) it will be easier to install (no need to
> insta
Robert Haas wrote:
> On Mon, Nov 2, 2009 at 10:14 AM, Euler Taveira de Oliveira
> wrote:
>> BTW, are you going to submit another WIP patch for next commitfest?
>
> Well, Heikki was going to keep working on this and Hot Standby between
> CommitFests "until it gets committed", but things seem to be
Jeff Davis writes:
> On Mon, 2009-11-02 at 08:25 +, Peter Eisentraut wrote:
>> I think the word CHECK should be avoided completely in this syntax, to
>> avoid confusion with CHECK constraints.
> This is an easy change. I don't have a strong opinion, so the only thing
> I can think to do is as
Steve Atkins writes:
> I've also seen it with winzip. Again, ISTR that the exact limits were
> obscure but that restricting the path to less than 100 characters
> avoided any problems.
Hmm. It strikes me that the names seen by tar include "postgresql-x.y.z/".
The only file paths that approach 10
On Mon, 2009-11-02 at 08:25 +, Peter Eisentraut wrote:
> I think the word CHECK should be avoided completely in this syntax, to
> avoid confusion with CHECK constraints.
This is an easy change. I don't have a strong opinion, so the only thing
I can think to do is ask for a vote.
Do you have a
On Mon, 2009-11-02 at 07:38 +, Simon Riggs wrote:
> It bothers me that we would have completely separate syntax for this
> feature as opposed to normal SQL. It also doesn't make it easy to
> interpret from the business statement to the implementation. Notice that
> the "," above means "AND".
Y
On Mon, Nov 2, 2009 at 11:31 AM, Tom Lane wrote:
> Another interesting property
> of this approach is that it'd fix the longstanding user complaint
> that constructions like
> if (TG_OP = 'INSERT' and NEW.foo = 'bar') ...
> fail prematurely. The executor would never demand the value
> of
Robert Haas escribió:
> I don't see anything in this code that is very rel-specific, so I
> think it would be possible to implement spcoptions by just defining
> RELOPT_KIND_TABLESPACE and ignoring the irony, but that has enough of
> an unsavory feeling that I'm sure someone is going to complain a
2009/11/2 Tom Lane :
> One of the interesting properties of Oracle-compatible variable
> references in plpgsql is that the set of variables referenced by a
> given query could change during a forced replan. For example,
> consider
>
> declare x int;
> r record;
> ...
>
On Oct 31, 2009, at 7:30 PM, Tom Lane wrote:
Alexey Klyukin writes:
One of our customers is running 8.2.14 and use a couple of pl/perl
and
pl/perlu functions written by CMD. Everything worked normally until
they tried to call one particular pl/perl function from pl/perl via
spi. It appears
One of the interesting properties of Oracle-compatible variable
references in plpgsql is that the set of variables referenced by a
given query could change during a forced replan. For example,
consider
declare x int;
r record;
...
for r in select x,y from t
Ivo Raisr wrote:
Hi guys,
I hacked PostgreSQL 8.4.1 libpq and added a new function to specify
resultFormat for individual result columns.
Are you interested in a patch?
(http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html says:
There is not currently a provision to obtain different re
On Mon, Nov 02, 2009 at 12:00:29PM +0100, Ivo Raisr wrote:
> Hi guys,
> I hacked PostgreSQL 8.4.1 libpq and added a new function to specify
> resultFormat for individual result columns.
> Are you interested in a patch?
New features only go into git head (aka CVS TIP), so for future
reference, only
On Mon, Nov 2, 2009 at 10:14 AM, Euler Taveira de Oliveira
wrote:
> BTW, are you going to submit another WIP patch for next commitfest?
Well, Heikki was going to keep working on this and Hot Standby between
CommitFests "until it gets committed", but things seem to be stalled
at the moment, possib
Fujii Masao escreveu:
> IMO, walreceiver should be a subprocess of postmaster for
> the following reasons.
>
+1. I agree that the first version should be as close as possible to
postmaster. My points are: (i) it will be easier to install (no need to
install another third-party software), (ii) it w
On Mon, Nov 2, 2009 at 6:00 AM, Ivo Raisr wrote:
> Hi guys,
> I hacked PostgreSQL 8.4.1 libpq and added a new function to specify
> resultFormat for individual result columns.
> Are you interested in a patch?
>
> (http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html says:
> There is not
Hi guys,
I hacked PostgreSQL 8.4.1 libpq and added a new function to specify
resultFormat for individual result columns.
Are you interested in a patch?
(http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html says:
There is not currently a provision to obtain different result columns
in dif
Fujii Masao writes:
> I wonder why backup_label isn't automatically removed
> in normal crash recovery case.
Removing it automatically could be catastrophic if done incorrectly, no?
> If that's intentional, a clusterware for shared disk
> failover system should remove backup_label whenever
> doi
On Nov 2, 2009, at 5:06 AM, Fujii Masao wrote:
Hi,
Recently, the development of SR is not progressing because of
the indecision on whether walreceiver should be a subprocess
of the startup process (i.e., a stand-alone program), or of
postmaster. Since time is running out, I'd like to discuss
a
On Sun, 2009-11-01 at 18:07 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > The syntax be easier to read if it was stated as a comparison
> > e.g. in the circle example
> > CHECK ( NOT (NEW.c && c)) USING GIST
>
> I don't think this is a good idea at all. NEW is a nonstandard
> Postgres-ism,
On Mon, 2009-11-02 at 13:02 +0200, Peter Eisentraut wrote:
>
> > Also, I'll be happy if you can also upload .bz2 file (for the lazy
> RPM
> > packages who does not want to play with his spec files a lot).
>
> Done. I'll also add that to the build scripts for the new alpha.
Thanks Peter.
Regard
On Wed, 2009-10-28 at 22:28 +0200, Devrim GÜNDÜZ wrote:
> Peter, could you please provide md5sum for alpha2 tarball? I know we
> missed in alpha1. It would be better if the original packager would
> upload the md5sum.
I was struggling internally with this one, because the tools currently
in use ar
Hi,
Recently, the development of SR is not progressing because of
the indecision on whether walreceiver should be a subprocess
of the startup process (i.e., a stand-alone program), or of
postmaster. Since time is running out, I'd like to discuss
about this and advance the project.
The related thr
Fujii Masao wrote:
> When a crash occurs before calling pg_stop_backup(),
> the subsequent crash recovery causes the FATAL error
> and outputs the following HINT message.
>
> If you are not restoring from a backup, try removing the file
> \"%s/backup_label\"."
>
> I wonder why backup_label is
Jeff Davis writes:
> If I understand what you're saying, you're alluding to a type where you
> can do things like:
> RANGE(timestamptz)
> which would be equivalent to a PERIOD.
The RANGE approach sounds so much better from here, as I have the
prefix_range example nearby... it'd be nice if it co
On Sun, 2009-11-01 at 22:42 +, Simon Riggs wrote:
> The current patch writes the syntax like this
> EXCLUSION USING gist (c CHECK WITH &&)
> makes it look like a table constraint, yet it clearly refers to a
> single
> column. That looks very clumsy to read, to my eyes.
I think the word CHECK
39 matches
Mail list logo
