On Tue, Apr 1, 2008 at 5:40 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> Apologies if this gets duplicated - original seems to have been dropped due
> to patch size - this time I am sending it gzipped.
>
just for the record, this patch doesn't apply cleanly to CVS
--
regards,
Jaime Casanova
Gregory Stark <[EMAIL PROTECTED]> writes:
> The patch is simple enough and if it was all it would take I would say let's
> go ahead even if it's something only Josh would use. But it isn't anywhere
> near everything you would expect to have this work cleanly. Really you would
> want to be able to t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Saturday, April 05, 2008 03:37:08 +0100 Gregory Stark
<[EMAIL PROTECTED]> wrote:
> It probably would be neat if the email footer thingy added a url to each email
> it distributed via the lists pointing to the permanent message-id-based url i
There's a patch on the patch list to implement \# in psql.
Coincidentally this seems to be of a piece with the recent "alias"
discussions. People seem to be intent on turning psql into a full blown unix
shell including all the weird quirky rough edges of the csh family tree.
I'm big on the retro
* Andrew Dunstan <[EMAIL PROTECTED]> [080404 21:54]:
> >Well, I'm happy to go back to lurking for now... Maybe after a few
> >years I'll have heard and seen more discussions and know better next
> >time ;-)
> Don't take it personally.
I don't, and for the record, I'm actually quite glad that th
On Fri, 04 Apr 2008 22:37:17 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think ultimately we are going to have to remove the patches email
> > list and require patch submitters to add their patches to a patch
> > tracker.
>
> That's outright silly.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > + CREATE OR REPLACE FUNCTION dblink_current_query ()
> > + RETURNS text
> > + AS 'SELECT current_query()'
> > + LANGUAGE SQL;
>
> Needs to be pg_catalog.current_query
Oh, good point. Done.
--
Bruce Momjian <[EMAIL PROTECTED]>
Tom Lane wrote:
> The patch queue is by definition transient --- nobody particularly cares
> about what its past state was, as shown by the fact that you've gotten
> along for years with an implementation that's incapable of recalling
> past state. (Now I do like the idea that a wiki-based patch q
Bruce Momjian <[EMAIL PROTECTED]> writes:
> + CREATE OR REPLACE FUNCTION dblink_current_query ()
> + RETURNS text
> + AS 'SELECT current_query()'
> + LANGUAGE SQL;
Needs to be pg_catalog.current_query
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Bruce Momjian wrote:
> I see what happened. The author said he had made the change, but the
> patch didn't contain it:
>
> http://archives.postgresql.org/pgsql-patches/2007-05/msg00132.php
> > > FWIW I think you should still provide dblink_current_query, even if
> > > it's
> > >
> > > o
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think ultimately we are going to have to remove the patches email list
> and require patch submitters to add their patches to a patch tracker.
That's outright silly. The email list and archives are a critical part
of what we do, because they provide
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>
>> The hard part is reading the email and figuring out
>> what status the patch is in.
>
> Certainly. What we've got to do is make sure that after someone has
> made that decision, it doesn't cost them a couple o
Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > "Bruce Momjian" <[EMAIL PROTECTED]> writes:
> >> Basically a Wiki takes 10x more time for me to modify something, so
> >> unless I get another 9 people to do the same amount of work I do on
> >> tracking, we are going to fall behind.
"Greg Smith" <[EMAIL PROTECTED]> writes:
> On Fri, 28 Mar 2008, Gregory Stark wrote:
>
>> I described which interfaces worked on Linux and Solaris based on empirical
>> tests. I posted source code for synthetic benchmarks so we could test it on a
>> wide range of hardware. I posted graphs based o
"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes:
> - I think normal index scans could benefit from this (it was measurable
> when I was playing with AIO in postgres a few years back).
I don't want to torture any existing code paths to get prefetching to work.
Heikki suggested I take advantag
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>> Basically a Wiki takes 10x more time for me to modify something, so
>> unless I get another 9 people to do the same amount of work I do on
>> tracking, we are going to fall behind. I am not willing to increa
Aidan Van Dyk wrote:
Unfortunately, the current state really does seem to mean that the
"feature of modularity" really is the kiss of death, since things are
actively pushed out from core to be modular projects, making them
unusable for most people...
Really? What have we pushed out that
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Basically a Wiki takes 10x more time for me to modify something, so
> unless I get another 9 people to do the same amount of work I do on
> tracking, we are going to fall behind. I am not willing to increase the
> amount of time I already spend doing
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > > >> Alvaro Herrera wrote:
> > > >>> I think the agreement was that dblink_current_query was to be
> > > >>> implemented on top of this. In fact I don't see any reason not to.
>
> > OK. Did someone mention this before because I don't remember i
Bruce Momjian wrote:
> > >> Alvaro Herrera wrote:
> > >>> I think the agreement was that dblink_current_query was to be
> > >>> implemented on top of this. In fact I don't see any reason not to.
> OK. Did someone mention this before because I don't remember it and the
> patch removed the dblink
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 5, 2008 at 12:14 PM, Gregory Stark wrote:
> "Brendan Jurd" writes:
> > Okay, but what on earth is "\c&" and what would you expect it to do
> > when it "works"? I suppose you're connecting to a database, but
> > somehow I don't think y
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> On Fri, 4 Apr 2008 20:22:51 -0400
> Aidan Van Dyk <[EMAIL PROTECTED]> wrote:
>> Unfortunately, the current state really does seem to mean that the
>> "feature of modularity" really is the kiss of death, since things are
>> actively pushed out from
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> On Sat, Apr 5, 2008 at 10:00 AM, Gregory Stark wrote:
>> Regardless of whether we go ahead with this (and I'm not fond of it
>> primarily
>> because I want \c& to "work"),
>
> Okay, but what on earth is "\c&" and what would you expect it to do
> whe
Alvaro Herrera wrote:
> BTW, Greg Stark already dumped the patch queue into a wiki page some
> time ago: http://wiki.postgresql.org/wiki/CommitFest:Bruce Do you think
> that's more useful than the other commitfest layout? I don't.
No.
The bottom line is that I used to do this tracking in my own
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 5, 2008 at 10:00 AM, Gregory Stark wrote:
> Regardless of whether we go ahead with this (and I'm not fond of it primarily
> because I want \c& to "work"),
Okay, but what on earth is "\c&" and what would you expect it to do
when it "work
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >> Alvaro Herrera wrote:
> >>> I think the agreement was that dblink_current_query was to be
> >>> implemented on top of this. In fact I don't see any reason not to.
> >>
> >> Really? It seemed like just dupl
Dawid Kuroczko wrote:
> 2. Do we want \G? I would say "yes". ;) But it should get discussed.
> pgsql-general perhaps?
No. We have had little demand for the auto, let alone a \G. Once we
have auto I don't see a use for \G.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
Ente
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> Alvaro Herrera wrote:
>>> I think the agreement was that dblink_current_query was to be
>>> implemented on top of this. In fact I don't see any reason not to.
>>
>> Really? It seemed like just duplicate functionality.
> It's c
On Fri, 4 Apr 2008 20:22:51 -0400
Aidan Van Dyk <[EMAIL PROTECTED]> wrote:
> Unfortunately, the current state really does seem to mean that the
> "feature of modularity" really is the kiss of death, since things are
> actively pushed out from core to be modular projects, making them
> unusable for
* Tom Lane <[EMAIL PROTECTED]> [080404 16:12]:
> And utterly, utterly insecure.
>
> The fact that the referenced object file is a "trusted" Postgres module
> isn't enough to make it safe --- the user can still play hob with the
> system by creating functions with the wrong argument/result types,
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
>> +1 for dropping this quirk. And, if there are no objections (or other
>> takers), I volunteer to write a patch.
> Regardless of whether we go ahead with this (and I'm not fond of it primarily
> because I wan
Gregory Stark escribió:
> I still see it much cleaner and much clearer for people reading the script to
> have something like
>
> \query dpkg perl-base*
This also helps to separate the namespaces for tab completion if you
want to use this in interactive mode.
--
Alvaro Herrera
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> +1 for dropping this quirk. And, if there are no objections (or other
> takers), I volunteer to write a patch.
Regardless of whether we go ahead with this (and I'm not fond of it primarily
because I want \c& to "work"), I think we would still be bet
Gregory Stark <[EMAIL PROTECTED]> writes:
> I suppose if all we want to do is assert that constructors don't create this
> situation we could have an assertion that calls the constructor a second time
> (with palloc generating garbage data) and compares the results with
> datumEqual.
After further
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> The alternative seems to be to forbid uninitialized pad bytes within
>>> Datums. That's not very pleasant to contemplate either, since it'll
>>> forever be vulnerable
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> That still puts the responsibility on the individual datatype author to
>> get it right. The case I'm most worried about is user-written datatypes
>> that are never going to magically acquire such asserts.
> It seems to me that working with two assumpt
Dawid Kuroczko escribió:
> Hmm, seems doable.
I think that the followup discussion leads to implementing just \G (and
\x auto).
> I think there should be a format Enum, which would take values like NORMAL,
> EXTENDED, and EXTENDED_ONCE -- but this would be a much more invasive patch.
> Oh, and c
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> The example I have in mind is Perl, as I have referred to before. It comes
> with
> a number of useful modules (e.g. File::Find, and CGI) that don't have to be in
> the perl core distribution but are very widely used and so having them there
> makes
On Thu, Apr 3, 2008 at 6:44 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Bruce Momjian escribió:
>
>
> > It seems more helpful if there were \x option to use extended format
> > only when the output is too wide. TODO already has:
> >
> > o Add auto-expanded mode so expanded output i
That still puts the responsibility on the individual datatype author to
get it right. The case I'm most worried about is user-written datatypes
that are never going to magically acquire such asserts.
It seems to me that working with two assumption (binary equal and
catalog-defined equal fun
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> The alternative seems to be to forbid uninitialized pad bytes within
>> Datums. That's not very pleasant to contemplate either, since it'll
>> forever be vulnerable to sins of omission.
> Just brainstorming here
Tom Lane wrote:
IMHO, the ideal situation would be that the only stuff in contrib is
stuff that needs to be maintained together with the core code --- an
example is pg_controldata, because it looks at data structures that
we change on a frequent basis. We need to be looking for ways to
increa
"Tom Lane" <[EMAIL PROTECTED]> writes:
> The alternative seems to be to forbid uninitialized pad bytes within
> Datums. That's not very pleasant to contemplate either, since it'll
> forever be vulnerable to sins of omission.
Just brainstorming here, I don't think this is a good solution but perh
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I would suggest a guc for the "safe" place and I would suggest it be a list
>> of
>> places. And I would suggest that for OS packagers they really want two
>> locations on that list, something like:
>> /usr/li
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> The alternative seems to be to forbid uninitialized pad bytes within
>> Datums. That's not very pleasant to contemplate either, since it'll
>> forever be vulnerable to sins of omission.
> Hmm, we can add to palloc random filling of allocated memory wit
Gregory Stark <[EMAIL PROTECTED]> writes:
> I would suggest a guc for the "safe" place and I would suggest it be a list of
> places. And I would suggest that for OS packagers they really want two
> locations on that list, something like:
> /usr/lib/postgresql/modules;/usr/local/lib/postgresql/mod
Greg Smith <[EMAIL PROTECTED]> writes:
> On Thu, 3 Apr 2008, Joshua D. Drake wrote:
>> IMO the core modules should be compiled via configure with something
>> like:
>> ./configure --enable-module=ALL
> If you really want to make the problems with using contrib modules go
> away, so they are a) in
On Sat, Apr 5, 2008 at 12:22 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Aidan Van Dyk" <[EMAIL PROTECTED]> writes:
>
> > What if you didn't need super-user privileges to load "C" functions, on
> > the conditions that:
> > 1) There is no / in the obj_file filename (or some other "sanitizing"
The alternative seems to be to forbid uninitialized pad bytes within
Datums. That's not very pleasant to contemplate either, since it'll
forever be vulnerable to sins of omission.
Hmm, we can add to palloc random filling of allocated memory with
--enable-cassert. It'll allow to catch such b
Gregory Stark wrote:
> "Greg Smith" <[EMAIL PROTECTED]> writes:
>
> > He wants to know how to automate turning an entire mbox file full of them
> > into
> > wiki markup, now how to do one at a time. Other people have been running
> > such
> > tools for Bruce but he doesn't have one he can becom
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Aidan Van Dyk" <[EMAIL PROTECTED]> writes:
>> What if you didn't need super-user privileges to load "C" functions, on
>> the conditions that:
>> 1) There is no / in the obj_file filename (or some other "sanitizing"
>> rules)
>> 2) You're database owner
I tracked down the problem reported here:
http://archives.postgresql.org/pgsql-admin/2008-04/msg00038.php
What it boils down to is that equal() doesn't see these two Consts
as equal:
{CONST
:consttype 1009
:consttypmod -1
:constlen -1
"Greg Smith" <[EMAIL PROTECTED]> writes:
> On Fri, 4 Apr 2008, Dave Page wrote:
>
>> We must be talking at cross purposes because I really cannot believe
>> you're asking me how to add a link to a wiki page :-o
>
> He wants to know how to automate turning an entire mbox file full of them into
> wi
Hello everybody!
Sorry for being off-topic, but I would like to ask if
anybody has ported sp-gist to 8.3?
Thanks
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Assuming others think something like this might be interesting, would
something to do this be an OK candidate for my first patch, if only to
start this ball rolling?
a.
* Gregory Stark <[EMAIL PROTECTED]> [080404 14:57]:
> "Aidan Van Dyk" <[EMAIL PROTECTED]> writes:
>
> > What if you didn't need
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > I think the agreement was that dblink_current_query was to be
> > implemented on top of this. In fact I don't see any reason not to.
>
> Really? It seemed like just duplicate functionality.
It's called "backwards compatibility". The nice thing
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Log Message:
> > ---
> > Implement current_query(), that shows the currently executing query.
> > At the same time remove dblink/dblink_current_query() as it is no longer
> > necessary
> > *BACKWARD COMPATIBILITY ISSUE* for dblink
>
> I thin
"Aidan Van Dyk" <[EMAIL PROTECTED]> writes:
> What if you didn't need super-user privileges to load "C" functions, on
> the conditions that:
> 1) There is no / in the obj_file filename (or some other "sanitizing"
>rules)
> 2) You're database owner
That's an interesting idea. It has the proper
Aidan Van Dyk wrote:
This was simply about changing the user permissions needed to run CREATE
FUNCTION ... LANGUAGE "C" so that distros/packages could have whatever
module they want packaged (in system RPM/DEB/PKG context) and available
on the system in a way that databases owners could instal
Bruce Momjian wrote:
> Log Message:
> ---
> Implement current_query(), that shows the currently executing query.
> At the same time remove dblink/dblink_current_query() as it is no longer
> necessary
> *BACKWARD COMPATIBILITY ISSUE* for dblink
I think the agreement was that dblink_current_
On Thu, 3 Apr 2008, Joshua D. Drake wrote:
IMO the core modules should be compiled via configure with something
like:
./configure --enable-module=ALL
If you really want to make the problems with using contrib modules go
away, so they are a) installed even by lazy ISPs who just do
compile/mak
On Fri, 4 Apr 2008, Dave Page wrote:
We must be talking at cross purposes because I really cannot believe
you're asking me how to add a link to a wiki page :-o
He wants to know how to automate turning an entire mbox file full of them
into wiki markup, now how to do one at a time. Other peopl
Bruce Momjian wrote:
Magnus, I am seeing this compile warning, I think related to work you
were doing:
guc.c:7116: warning: `assign_backslash_quote' defined but not used
Yup, that's mine, fixed.
//Magnus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
* Andrew Dunstan <[EMAIL PROTECTED]> [080404 09:35]:
>
>
> Aidan Van Dyk wrote:
> >This changes the game slightly from trying to get systems to come with
> >PostreSQL "modules" installed into PostgreSQL by default, to where
> >systems come with PostgreSQL "module" *packages* (rpms, debs, pkg, etc
* Andrew Dunstan <[EMAIL PROTECTED]> [080404 10:17]:
> Aidan Van Dyk wrote:
> >This was simply about changing the user permissions needed to run CREATE
> >FUNCTION ... LANGUAGE "C" so that distros/packages could have whatever
> >module they want packaged (in system RPM/DEB/PKG context) and availa
* Jeremy Drake <[EMAIL PROTECTED]> [080404 01:27]:
> My opinion is, it doesn't matter what you call the modules/contrib stuff
> if I can't use it, and I can't use it if it is not loaded in my
> database, and I can't load it without superuser privileges.
Would it be possible to "change" the rules
Aidan Van Dyk wrote:
This changes the game slightly from trying to get systems to come with
PostreSQL "modules" installed into PostgreSQL by default, to where
systems come with PostgreSQL "module" *packages* (rpms, debs, pkg, etc)
installed by default, and the DB owners can do the "PostgreSQL i
Magnus, I am seeing this compile warning, I think related to work you
were doing:
guc.c:7116: warning: `assign_backslash_quote' defined but not used
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your
On Thu, Apr 03, 2008 at 09:38:42PM -0400, Tom Lane wrote:
> Sam Mason <[EMAIL PROTECTED]> writes:
> > On Thu, Apr 03, 2008 at 03:57:38PM -0400, Tom Lane wrote:
> >> I liked the idea of allowing COPY FROM to act as a table source in a
> >> larger SELECT or INSERT...SELECT. Not at all sure what woul
On Thu, Apr 03, 2008 at 06:54:50PM +0100, Gregory Stark wrote:
> The big gotcha is what collation to use when comparing with data in the system
> tables, especially the shared system tables. I think we do need to define a
> database-wide encoding and collation to use for system tables. (Unless we c
On Fri, Apr 04, 2008 at 02:23:31PM +0530, Tom Dunstan wrote:
> Right. Which is why some of us have been suggesting a model where all
> modules currently in contrib are installed by default, but not enabled
> until a database owner actually issues some sort of "Install module
> foo" or whatever it l
On Fri, Apr 4, 2008 at 10:48 AM, Jeremy Drake <[EMAIL PROTECTED]> wrote:
> My opinion is, it doesn't matter what you call the modules/contrib stuff
> if I can't use it, and I can't use it if it is not loaded in my
> database, and I can't load it without superuser privileges.
Right. Which is w
On Thu, Apr 3, 2008 at 4:55 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > That seems like a *really* odd thing for one of the founders of the
> > world's most advanced OSS DBMS project to say. It's all relational
> > (which we do do pretty well) - we can add links to the wiki to threads
> > in
73 matches
Mail list logo
