Hello
2008/7/30 Hannu Krosing <[EMAIL PROTECTED]>:
> On Wed, 2008-07-30 at 07:29 +0200, Pavel Stehule wrote:
>> 2008/7/29 Hannu Krosing <[EMAIL PROTECTED]>:
>> > On Thu, 2008-07-17 at 19:13 -0400, Tom Lane wrote:
>> >> I've been working on the TABLE-function patch, and I am coming to the
>> >> con
On Wed, 2008-07-30 at 07:29 +0200, Pavel Stehule wrote:
> 2008/7/29 Hannu Krosing <[EMAIL PROTECTED]>:
> > On Thu, 2008-07-17 at 19:13 -0400, Tom Lane wrote:
> >> I've been working on the TABLE-function patch, and I am coming to the
> >> conclusion that it's really a bad idea for plpgsql to not ass
2008/7/29 Hannu Krosing <[EMAIL PROTECTED]>:
> On Thu, 2008-07-17 at 19:13 -0400, Tom Lane wrote:
>> I've been working on the TABLE-function patch, and I am coming to the
>> conclusion that it's really a bad idea for plpgsql to not associate
>> variables with output columns --- that is, I think we
Updated patch attached.
This patch addresses all of Alvaro's feedback except the new probes for
v3 protocol which will be submitted later along with the rest of the probes.
It also incorporates Tom's feedback as explained inline below.
I hope this patch is good to go for this commit fest. Wil
On Mon, Jul 28, 2008 at 02:49:01PM -0400, Tom Lane wrote:
> Andrew Gierth <[EMAIL PROTECTED]> writes:
> > "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
> > Tom> That whole business of using the EState to pass tuplestores back
> > Tom> and forth looks fundamentally broken to me anyway; there's jus
I've been thinking a little more about modifying views:
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00694.php
AFAICS, out of all of the things that ALTER TABLE is capable of doing,
there are only four that make any sense in the context of views:
(1) add a column
(2) drop a column
(3)
On Jul 29, 2008, at 16:45, Tom Lane wrote:
Nice! Does it also allow all of the casts to and from text to
implicitly work, e.g,
No, but we could think about that. Do we really want that to work for
any member of the string category? It seems a bit overly broad to me
...
I was thinking about
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> On Jul 29, 2008, at 15:35, Tom Lane wrote:
>> BTW, I did confirm (by temporarily hacking up TypeCategory()) that
>> causing citext to appear to be of STRING category eliminates the need
>> for the extra || operator and quote_literal() function that a
On Jul 29, 2008, at 15:35, Tom Lane wrote:
BTW, I did confirm (by temporarily hacking up TypeCategory()) that
causing citext to appear to be of STRING category eliminates the need
for the extra || operator and quote_literal() function that are in
the current citext code. So the proposed solutio
I wrote:
> "David E. Wheeler" <[EMAIL PROTECTED]> writes:
>> Anyway, would this issue then go away once the type stuff was added
>> and citext was specified as TYPE = 'S'?
> Yeah, that's the point of the proposal.
BTW, I did confirm (by temporarily hacking up TypeCategory()) that
causing citext
Heikki Linnakangas wrote:
Jan Urbański wrote:
Another thing are cstring_to_text_with_len calls. I'm doing them so I
can use bttextcmp in bsearch(). I think I could come up with a
dedicated function to return text Datums and WordEntries (read:
non-NULL terminated strings with a given length).
Hello Leiyonghua,
thanks for trying out Postgres-R.
leiyonghua wrote:
NOTICE: Applying for membership in the communication group...
NOTICE: Successfully joined the replication group. Now recovering schema...
so, i dont know what happened, pls give me some advice.
Please compile with '--enabl
On Jul 29, 2008, at 14:33, Tom Lane wrote:
That's exactly what I don't really want to do; if you are adding
aliases
*only* to get rid of ambiguity-errors, and not to alter functionality,
then I think you're doing the wrong thing. Adding more aliases can
easily make the situation worse.
Actu
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> Well, there are already citext aliases for all of those operators, for
> this very reason. There are citext aliases for a bunch of the
> functions, too (ltrim(), substring(), etc.), so I wouldn't worry about
> adding more. I've added more of th
On Jul 29, 2008, at 14:00, Tom Lane wrote:
Well, a rough estimate of the places where implicit coercion to text
might be relevant to resolving ambiguity is
select proname from pg_proc
where 'text'::regtype = any(proargtypes)
group by proname having count(*)>1;
select oprname from pg_operator
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> On Jul 29, 2008, at 13:12, Tom Lane wrote:
>> Given the present infrastructure I think the only way would be with
>> two more alias operators, text||citext and citext||text. But that way
>> madness lies.
> I suppose, then, that you're saying that t
On Jul 29, 2008, at 13:12, Tom Lane wrote:
Damn, I didn't even notice that! Can that be fixed?
Given the present infrastructure I think the only way would be with
two more alias operators, text||citext and citext||text. But that way
madness lies.
I suppose, then, that you're saying that the
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> On Jul 29, 2008, at 11:41, Tom Lane wrote:
>> and I notice that cases like
>> contrib_regression=# select 'a'::text || 'b'::citext;
>> ERROR: operator is not unique: text || citext
>> still don't work even though you put in an alias || operator.
>
On Tue, Jul 29, 2008 at 02:21:18PM -0400, Robert Haas wrote:
> +1 for CREATE OR REPLACE
>
> ...Robert
+1 for CREATE OR REPLACE from me, too :)
Cheers,
David.
--
David Fetter <[EMAIL PROTECTED]> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter X
Tom Lane napsal(a):
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Am Tuesday, 29. July 2008 schrieb Greg Sabino Mullane:
What's not stable about having Python 2.5?
I mean "stable" to mean "does not change (unnecessarily)".
I really don't understand Peter's objection here. This thread has
a
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Tue, 2008-07-29 at 12:46 -0400, Tom Lane wrote:
>> The feeling I had about it was that if we were adding
>> PROARGMODE_VARIADIC in 8.4 then there wasn't any very strong argument
>> not to add PROARGMODE_TABLE; any code looking at proargmodes is going
>
Tom Lane napsal(a):
Obviously the solution should involve a new column in pg_type and
a new type property in CREATE TYPE, but what should the representation
be? A full-on approach would make the type categories be real SQL
objects with their own system catalog and reference them by OID,
but I
On Jul 29, 2008, at 11:41, Tom Lane wrote:
Okay, it's committed with minor revisions --- the biggest thing I
fixed
was the lack of an uninstall script.
Great, thanks!
I saw what you were talking about in terms of still having some
casting
issues: having to put in a quote_literal(citext)
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> Sure. It's mostly just additional casts and tests. I'd be happy to
> integrate it into your commit.
Okay, it's committed with minor revisions --- the biggest thing I fixed
was the lack of an uninstall script.
I saw what you were talking about in
+1 for CREATE OR REPLACE
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jul 29, 2008, at 11:01, Tom Lane wrote:
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
Damn, I was away from mail yesterday; sorry. I have some revisions,
mostly improving casting compatibility with text.
Huh? What's to improve?
I know that you're still fooling with the regexp functions,
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> Damn, I was away from mail yesterday; sorry. I have some revisions,
> mostly improving casting compatibility with text.
Huh? What's to improve?
I know that you're still fooling with the regexp functions, but I
figured that could be added later.
Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
"Tom Lane" <[EMAIL PROTECTED]> writes:
I really don't understand Peter's objection here. This thread has
already consumed more person-time than I spent on applying the
back-patch.
Well I certainly wouldn't expec
On Tue, 2008-07-29 at 12:46 -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Why is PROARGMODE_TABLE needed at all ?
>
> Personally I would rather not have it, but Pavel insists it's needed
> for standards compliance in PL/PSM, where output TABLE columns are not
> supposed to
On Tue, 29 Jul 2008, Peter Eisentraut wrote:
Someone taking the step from Python 2.4 to 2.5 might as well do a major
upgrade of PostgreSQL as well.
It takes a few seconds to upgrade Python versions, and I know I've
installed Python 2.5 from source on a production server before while not
touc
On Jul 29, 2008, at 08:58, Tom Lane wrote:
It seems that the majority opinion is in favor of including citext
in contrib, so I will go work on that now.
Damn, I was away from mail yesterday; sorry. I have some revisions,
mostly improving casting compatibility with text. Tom, have you
commi
Tom> RETURNS TABLE columns semantically just the same as OUT parameters.
I hope you are not proposing to create another case of crippled OUT
parameters that are quite problematic to use together with inline sql or has
it gotten fixed on the road (we are still using 8.2 on most of our servers).
On
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Why is PROARGMODE_TABLE needed at all ?
Personally I would rather not have it, but Pavel insists it's needed
for standards compliance in PL/PSM, where output TABLE columns are not
supposed to have names visible within the function.
One reason to have it
On Thu, 2008-07-17 at 19:13 -0400, Tom Lane wrote:
> I've been working on the TABLE-function patch, and I am coming to the
> conclusion that it's really a bad idea for plpgsql to not associate
> variables with output columns --- that is, I think we should make
> RETURNS TABLE columns semantically j
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> I really don't understand Peter's objection here. This thread has
>> already consumed more person-time than I spent on applying the
>> back-patch.
> Well I certainly wouldn't expect us to feel obligated to spe
On Jul 28, 2008, at 18:31, Tom Lane wrote:
To upgrade from citext, I expect
that what one will have to do is to alter the column to change its
data type from citext to TEXT + collation.
What I'm wondering is how closely that will match the semantics of the
contrib module ...
By "semantics" d
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Monday, 28. July 2008 schrieb Tom Lane:
>> But to define such a domain, you'd have to commit to a case-insensitive
>> version of a specific collation, no? citext currently means "case
>> insensitive version of whatever the database's default collat
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Am Tuesday, 29. July 2008 schrieb Greg Sabino Mullane:
>>> What's not stable about having Python 2.5?
>
>> I mean "stable" to mean "does not change (unnecessarily)".
>
> I really don't understand Peter's objec
"Robert Haas" <[EMAIL PROTECTED]> writes:
> The question of using up all the bits seems purely speculative to me
> at this point. I agree that we don't want to fritter them away, but
> this is the only TODO item proposes using any of those bits. Tom's
> complaint about your patch seems to have be
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Tuesday, 29. July 2008 schrieb Greg Sabino Mullane:
>> What's not stable about having Python 2.5?
> I mean "stable" to mean "does not change (unnecessarily)".
I really don't understand Peter's objection here. This thread has
already consumed more
Jorgen Austvik - Sun Norway wrote:
> The attached patch makes pg_regress write converted files to
> /sql and /expected, which is one way to make it read
> and write to the same directory. Tested on Solaris x86 with pgsql "make
> check" and standalone.
I think this breaks VPATH builds in bot
Does anybody know if there's a reason why the ident code lives in hba.c,
but all other authentication code lives in auth.c? Is it just the fact
that ident supports the pg_ident.conf file, for which the processing is
located there, or is there some deeper reason?
I came across this while looking at
Andrew Dunstan wrote:
Greg Smith wrote:
On Wed, 23 Jul 2008, Kevin Grittner wrote:
In our scripts we handle this by copying to a temp directory on the
same mount point as the archive directory and doing a mv to the
archive location when the copy is successfully completed. I think
that this e
Stephen R. van den Berg wrote:
>The fetch_row() function actually returns an array for each row, where
>the individual columns are already parsed and converted into the native
>Pike formats for handling.
A typical (low level) usage sequence in Pike looks like this:
object db;
object q;
a
Peter Eisentraut napsal(a):
Am Tuesday, 29. July 2008 schrieb Greg Sabino Mullane:
Why would anyone running PostgreSQL 8.1 in production upgrade their
stable server to Python 2.5, and remove Python 2.4 in the process?
Because the keep their operating system up to date, and because we still
do n
Hi,
with regards to --inputdir, --srcdir, --outputdir and --schedule,
pg_regress does something like this:
convert files in /input, and place them in ./sql
convert files in /output, and place them in ./expected
read schedule from
for each test in schedule:
read test from /sql/.sql
read
* Robert Haas ([EMAIL PROTECTED]) wrote:
> > We've been through this before, I believe.. The concern is that it
> > chews up another bit in the acl structure, leaving not a huge number
> > left. My suggested approach to fixing this was to split the "grantable"
> > bits up from the regular usage b
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
> Am Tuesday, 29. July 2008 schrieb Stephen Frost:
> > I'd certainly like to see a truncate permission, I wrote a patch for it
> > myself back in January of 2006. That thread starts here:
> >
> > http://archives.postgresql.org/pgsql-patches/2006-01/msg
> We've been through this before, I believe.. The concern is that it
> chews up another bit in the acl structure, leaving not a huge number
> left. My suggested approach to fixing this was to split the "grantable"
> bits up from the regular usage bits. That's, unfortunately, a
> non-trivial amou
Am Tuesday, 29. July 2008 schrieb Stephen Frost:
> I'd certainly like to see a truncate permission, I wrote a patch for it
> myself back in January of 2006. That thread starts here:
>
> http://archives.postgresql.org/pgsql-patches/2006-01/msg00028.php
>
> I think someone else submitted a patch for
Hello,
The following patches are updated ones of SE-PostgreSQL toward the HEAD of CVS.
[1/4]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r958.patch
[2/4]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r958.patch
[3/4]
http://sepgsql.googlecode.com/
Am Tuesday, 29. July 2008 schrieb Greg Sabino Mullane:
> > Why would anyone running PostgreSQL 8.1 in production upgrade their
> > stable server to Python 2.5, and remove Python 2.4 in the process?
>
> Because the keep their operating system up to date, and because we still
> do not have any sort o
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> I notice that we now have four buildfarm members failing in the 8.1
>> branch, with symptoms indicating that they are running python 2.5,
>> which pre-8.2 plpython has known incompatibilities with. I think
>> it's high time we back-patched t
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
> Am Sunday, 27. July 2008 schrieb Robert Haas:
> > Here's a patch implementing the TODO item "Add a separate TRUNCATE
> > permission". Hopefully I found all the bits that needed to be
> > modified to make this work.
>
> Looks very good to me.
We've
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> In my opinion, you are starting this project from the wrong end. I would
> suggest you approach it like this:
>
> - Find some collation implementations
> - Patch PostgreSQL to link with them
Well I think the feeling is that we may as well start w
Not so sure about omitting OR REPLACE. In my experience it is more often
needed than not. Main argument for omitting might be to protect hackers from
carelesse users :)
On Wed, Jul 23, 2008 at 5:50 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
> > At 2008
Limited offer, get it while it's hot:
http://admin.cuci.nl/pgsql.pike.driver.tar.gz.bin
I relicensed it under BSD now, put up proper copyright notices, and
included the accelleratorclass for amusement (the module works without
the accellerator class, but it's about 10 times slower than libpq then
Marko is talking about types created with CREATE TYPE
CREATE FUNCTION fraud.get_user_status(
i_key_user text
) RETURNS ret_get_user_status AS
$$
Current pg_dump annoyingly removes schem reference from type.
On Wed, Jul 23, 2008 at 6:19 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kr
At 2008-07-23 10:50:03 -0400, [EMAIL PROTECTED] wrote:
>
> > What would the function return? "CREATE OR REPLACE FUNCTION ..."?
>
> I think I'd go with CREATE FUNCTION for simplicity.
OK, I have a mostly working pg_get_functiondef now, and some questions
about the remaining pieces:
1. Why is "pro
Am Tuesday, 1. July 2008 schrieb Radek Strnad:
> I'm sending part of the code that I've done and is available for reviewing
> and I'm asking for your comments and some help because I'm new to
> PostgreSQL.
>
> Proposal: http://archives.postgresql.org/pgsql-hackers/2008-05/msg00857.php
>
> The code
Am Sunday, 27. July 2008 schrieb Robert Haas:
> Here's a patch implementing the TODO item "Add a separate TRUNCATE
> permission". Hopefully I found all the bits that needed to be
> modified to make this work.
Looks very good to me.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
Jan Urbański wrote:
Another thing are cstring_to_text_with_len calls. I'm doing them so I
can use bttextcmp in bsearch(). I think I could come up with a dedicated
function to return text Datums and WordEntries (read: non-NULL
terminated strings with a given length).
Just keep them as cstrings
Am Monday, 28. July 2008 schrieb Tom Lane:
> I notice that we now have four buildfarm members failing in the 8.1
> branch, with symptoms indicating that they are running python 2.5,
> which pre-8.2 plpython has known incompatibilities with. I think
> it's high time we back-patched those compatibil
Am Monday, 28. July 2008 schrieb Tom Lane:
> But to define such a domain, you'd have to commit to a case-insensitive
> version of a specific collation, no? citext currently means "case
> insensitive version of whatever the database's default collation is".
So in the future, someone using citext w
Heikki Linnakangas wrote:
Jan Urbański wrote:
Here's a WIP patch implementing an oprrest function for tsvector @@
tsquery and tsquery @@ tsvector.
The idea is (quoting a comment)
/*
* Traverse the tsquery preorder, calculating selectivity as:
*
* selec(left_oper) * selec(right_oper) in A
Jan Urbański wrote:
Here's a WIP patch implementing an oprrest function for tsvector @@
tsquery and tsquery @@ tsvector.
The idea is (quoting a comment)
/*
* Traverse the tsquery preorder, calculating selectivity as:
*
* selec(left_oper) * selec(right_oper) in AND nodes,
*
* selec(lef
66 matches
Mail list logo
