[HACKERS] fulltext searching via a custom index type

2003-12-26 Thread Eric Ridge
idxstuff on test using xapian (stuff); create index idxmore_stuff on test using xapian (more_stuff); insert into test (stuff, more_stuff) values ('this is stuff', 'this is more stuff'); insert into test (stuff, more_stuff) values ('my name is eric ridge', 'i like to drink beer

Re: [HACKERS] fulltext searching via a custom index type

2003-12-26 Thread Eric Ridge
On Dec 26, 2003, at 3:22 PM, Tom Lane wrote: 3) How does one get the $PGDATA directory? DataDir. Why should you care? An index AM that wants to know this is probably broken IMHO; it's certainly trying to do something that's outside the charter of index AMs, and is likely to cause lots of

Re: [HACKERS] fulltext searching via a custom index type

2003-12-26 Thread Eric Ridge
On Dec 26, 2003, at 4:04 PM, Tom Lane wrote: Eric Ridge [EMAIL PROTECTED] writes: Xapian has it's own storage subsystem, and that's what I'm using to store the index... not using anything internal to postgres (although this could change). I would say you have absolutely zero chance of making

Re: Postgres + Xapian (was Re: [HACKERS] fulltext searching via a custom index type )

2004-01-05 Thread Eric Ridge
On Jan 2, 2004, at 4:54 PM, Alvaro Herrera wrote: I think your approach is too ugly. You will have tons of problems the minute you start thinking about concurrency (unless you want to allow only a single user accessing the index) It might be ugly, but it's very fast. Surprisingly fast, actually.

Re: Postgres + Xapian (was Re: [HACKERS] fulltext searching via a custom index type )

2004-01-08 Thread Eric Ridge
Thanks to everyone that provided input about this idea. After taking everything into consideration and talking with Olly Betts from the Xapian project, what I'm going to do is implement a btree that supports multiple roots and an tag value of arbitrary length for each item in the tree. Then

[HACKERS] User Defined Functions/AM's inherently slow?

2004-01-17 Thread Eric Ridge
I've created a stub AM that literally does nothing. It indexes nothing. It scans for nothing. Nadda. It does just enough work to specify return values that prevent PG from dumping core. What I've found is that this stub AM, compiled with the same options as postgres itself (-O2

Re: [HACKERS] User Defined Functions/AM's inherently slow?

2004-01-17 Thread Eric Ridge
On Jan 17, 2004, at 10:22 PM, Tom Lane wrote: Eric Ridge [EMAIL PROTECTED] writes: I've created a stub AM that literally does nothing. It's not possible for an index AM to do nothing, at least not for an indexscan. It has to return tuple pointers. What are you doing for that? costestimate

Re: [HACKERS] User Defined Functions/AM's inherently slow?

2004-01-17 Thread Eric Ridge
On Jan 17, 2004, at 10:22 PM, Tom Lane wrote: Eric Ridge [EMAIL PROTECTED] writes: I've created a stub AM that literally does nothing. It's not possible for an index AM to do nothing, at least not for an indexscan. It has to return tuple pointers. What are you doing for that? I should have

Re: [HACKERS] User Defined Functions/AM's inherently slow?

2004-01-17 Thread Eric Ridge
On Jan 17, 2004, at 11:27 PM, Tom Lane wrote: Eric Ridge [EMAIL PROTECTED] writes: costestimate: { PG_RETURN_VOID(); } This at least needs to set some values into the output parameters --- zeroes are okay, not setting them at all isn't. I'm surprised the planner doesn't go nuts

Re: [HACKERS] User Defined Functions/AM's inherently slow?

2004-01-17 Thread Eric Ridge
On Jan 17, 2004, at 11:33 PM, Tom Lane wrote: The difference between total runtime and the top plan node's runtime has to represent plan startup/shutdown time. I'm suspicious that your stubs are somehow not initializing something, though on first glance I do not see what. I can't see anything

Re: [HACKERS] User Defined Functions/AM's inherently slow?

2004-01-17 Thread Eric Ridge
On Jan 18, 2004, at 1:34 AM, Christopher Kings-Lynne wrote: Theory B would be that there's some huge overhead in calling non-built-in functions on your platform. We do know that looking up a C function is significantly more expensive than looking up a builtin function, but there should only

Re: [HACKERS] Question about indexes

2004-01-30 Thread Eric Ridge
On Jan 30, 2004, at 6:31 AM, Bruce Momjian wrote: I like the idea of building in-memory bitmapped indexes. Me too (FWIW)! This thread is really interesting as the whole idea would help to solve the biggest issue with my (currently stalled) project to integrate Xapian as a full-text search

Re: [HACKERS] User Defined Functions/AM's inherently slow?

2004-03-28 Thread Eric Ridge
I don't have the original thread in my inbox anymore, so for reference: http://groups.google.com/groups?hl=enlr=ie=UTF-8oe=UTF -8selm=20129.1074484755%40sss.pgh.pa.us Tom Lane last said: I have committed a patch into CVS HEAD --- give it a try. It took me awhile, but I finally got around to

Re: [HACKERS] [GENERAL] Can't Build 7.3.4 on OS X

2003-09-21 Thread Eric Ridge
On Sep 21, 2003, at 3:11 PM, Tom Lane wrote: Great. I was afraid it might have been new with 10.2. Also, 7.3.4 doesn't link on the OS X 10.3 beta's. Apparently tas is never being defined. I could never fix this. In the list archives I found all sorts of references to tas()/TAS and older

Re: [HACKERS] [GENERAL] Can't Build 7.3.4 on OS X

2003-09-21 Thread Eric Ridge
On Sep 21, 2003, at 3:11 PM, Tom Lane wrote: BTW, is anyone interested in looking into whether we can be made to build without using either flag? I tried it and saw a number of I did this... before I knew about -no-cpp-precomp. :( I read all about -traditional-cpp in the gcc man page, but

Re: [HACKERS] [GENERAL] Can't Build 7.3.4 on OS X

2003-09-22 Thread Eric Ridge
On Sep 21, 2003, at 9:03 PM, Tom Lane wrote: Eric Ridge [EMAIL PROTECTED] writes: any ideas here? 7.3.2 and 7.4beta3 compile just fine (I noticed that 7.4 has something more cross-platform for tas). What happened in 7.3.4 that broke it? That makes no sense at all --- AFAICT there were

Re: [HACKERS] bug in SignalSomeChildren

2010-12-21 Thread Eric Ridge
On Mon, Dec 20, 2010 at 3:36 PM, Martijn van Oosterhout klep...@svana.org wrote: On Mon, Dec 20, 2010 at 03:08:02PM -0500, Robert Haas wrote: The attached patch appears to work correctly on MacOS X.  I did check, BTW: getppid() in the attached process returns gdb's pid.  Poor! This appears to

Re: [HACKERS] bug in SignalSomeChildren

2010-12-21 Thread Eric Ridge
On Tue, Dec 21, 2010 at 2:33 PM, Robert Haas robertmh...@gmail.com wrote: The point of the patch was to improve cases where attaching gdb *didn't* work well.  Any cases where it was already working for you aren't going to be made worse by this. Okay, great. Thanks for the clarification. eric

[HACKERS] Thoughts on SELECT * EXCLUDING (...) FROM ...?

2011-10-29 Thread Eric Ridge
Would y'all accept a patch that extended the SELECT * syntax to let you list fields to exclude from the A_Star? Quite regularly I'll be testing queries via psql and want to see all the columns from a fairly wide table except maybe a giant text or xml column. A syntax like: SELECT *

Re: [HACKERS] Thoughts on SELECT * EXCLUDING (...) FROM ...?

2011-10-29 Thread Eric Ridge
On Sat, Oct 29, 2011 at 6:35 PM, Stephen Frost sfr...@snowman.net wrote: Maybe the SQL spec says something about this and nobody's done the work yet? I don't know of anything like this in the spec.  Also, there would be concern about this possibly going against spec, breaking possibly valid

Re: [HACKERS] Thoughts on SELECT * EXCLUDING (...) FROM ...?

2011-10-30 Thread Eric Ridge
On Sun, Oct 30, 2011 at 1:51 PM, Eric B. Ridge e...@tcdi.com wrote: eric PROPRIETARY AND COMPANY CONFIDENTIAL COMMUNICATIONS snip my bad. Switched email accounts without realizing. :( eric -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Thoughts on SELECT * EXCLUDING (...) FROM ...?

2011-10-30 Thread Eric Ridge
On Sun, Oct 30, 2011 at 2:54 PM, Robert Haas robertmh...@gmail.com wrote: OTOH, I'm slightly afraid of how much work it would take to implement this properly. I think first, the A_Star node struct will need to be expanded to include a List of qualified column references to exclude. From

Re: [HACKERS] Thoughts on SELECT * EXCLUDING (...) FROM ...?

2011-10-30 Thread Eric Ridge
On Sun, Oct 30, 2011 at 3:17 PM, Tom Lane t...@sss.pgh.pa.us wrote: It's entirely possible that it will get bounced on standards-compliance grounds. And that's a perfectly valid reason to reject it. In particular, I don't think it's acceptable to introduce a new reserved keyword for this

Re: [HACKERS] Thoughts on SELECT * EXCLUDING (...) FROM ...?

2011-10-30 Thread Eric Ridge
On Sun, Oct 30, 2011 at 3:38 PM, Mark Mielke m...@mark.mielke.cc wrote: Stupid question: Is this just a display thing? Well, it's a display thing as much as any SELECT statement (especially via psql) is a display thing. It's more like I want all 127 columns, except the giant ::xml column, and

Re: [HACKERS] Thoughts on SELECT * EXCLUDING (...) FROM ...?

2011-10-30 Thread Eric Ridge
On Sun, Oct 30, 2011 at 4:03 PM, Tom Lane t...@sss.pgh.pa.us wrote: That's just a gut feeling, I've not tried it ... but the proposed syntax sure looks a lot like a call to a function named EXCLUDING. I think what makes it okay is that its new use is only defined to immediately follow an

Re: [HACKERS] Thoughts on SELECT * EXCLUDING (...) FROM ...?

2011-10-30 Thread Eric Ridge
On Sun, Oct 30, 2011 at 4:43 PM, Darren Duncan dar...@darrenduncan.net wrote:  SELECT foo.* EXCLUDING foo.x, bar.* EXCLUDING bar.y, baz.z, (a+b) AS c FROM ... Is that where you're going with this? Yes. It's basically a modifier to the star that immediately precedes it. In order to support

Re: [HACKERS] Thoughts on SELECT * EXCLUDING (...) FROM ...?

2011-10-30 Thread Eric Ridge
On Sun, Oct 30, 2011 at 3:17 PM, Tom Lane t...@sss.pgh.pa.us wrote: snip fails to not break anything else category. From what I've seen watching this list, you're usually right. :) It looks like it's perfectly okay to write: SELECT pg_class.* AS foo FROM pg_class; (with or without the AS)

Re: [HACKERS] Thoughts on SELECT * EXCLUDING (...) FROM ...?

2011-11-01 Thread Eric Ridge
On Tue, Nov 1, 2011 at 12:03 PM, Stephen Frost sfr...@snowman.net wrote:  Note- I haven't looked at the * production or tried to do anything w/ gram.y to support this yet, but it's a heck of a lot shorter.. My original thought, that I probably didn't explain too clearly, was to make the

Re: [HACKERS] Thoughts on SELECT * EXCLUDING (...) FROM ...?

2011-11-01 Thread Eric Ridge
On Tue, Nov 1, 2011 at 12:24 PM, Pavel Stehule pavel.steh...@gmail.com wrote: some other idea - but only for psql we can define a special values, that ensure a some necessary preexecution alchemy with entered query \pset star_exclude_names col1, col2, col3 \pset star_exclude_types xml,

Re: [HACKERS] Thoughts on SELECT * EXCLUDING (...) FROM ...?

2011-11-01 Thread Eric Ridge
On Tue, Nov 1, 2011 at 1:33 PM, Pavel Stehule pavel.steh...@gmail.com wrote: COPY (SELECT * EXCLUDING (a, b, c) FROM big query) TO 'somefile.csv' WITH CSV; sorry, I don't accept it. I am able to understand your request for adhoc queries. But not for COPY. I apologize if that example was

Re: [HACKERS] Thoughts on SELECT * EXCLUDING (...) FROM ...?

2011-11-02 Thread Eric Ridge
On Tue, Nov 1, 2011 at 11:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: Doesn't mean anything, I think --- the SQL standard seems to exclude it. It's fairly hard to prevent it at the grammar level, since we regard foo.* as a type of primitive expression, but I suspect it might be a good idea for

[HACKERS] pg_get_indexdef() doesn't quote string reloptions

2014-10-13 Thread Eric Ridge
Hi all! I've been working on implementing a custom index using the Index Access Method API and have the need for custom reloptions that are complex strings (ie, also contain non-alphaumerics). pg_get_indexdef() and pg_dump don't quote the reloption values, making a restore (or cut-n-paste of

Re: [HACKERS] Let's drop two obsolete features which are bear-traps for novices

2014-10-31 Thread Eric Ridge
On Fri, Oct 31, 2014 at 6:07 PM, Tom Lane t...@sss.pgh.pa.us wrote: I don't know if/when that will happen as such, but Simon was making noises about writing code to treat hash indexes as unlogged automatically, which would more or less fix the worst risks. That's not just a special case for

Re: [HACKERS] Weirdness using Executor Hooks

2015-06-18 Thread Eric Ridge
On Thu, Jun 18, 2015 at 8:07 PM, Eric Ridge eeb...@gmail.com wrote: According to pg_proc.probin, all 32 of my C language functions point to $libdir/my_extension_lib, That's a damn lie. The deployment server has a number of databases that have this extension installed and some of them have

Re: [HACKERS] Weirdness using Executor Hooks

2015-06-18 Thread Eric Ridge
On Thu, Jun 18, 2015 at 4:42 PM, Andres Freund and...@anarazel.de wrote: How does your _PG_init() actually look like? static ExecutorStart_hook_type prev_ExecutorStartHook = NULL; static ExecutorEnd_hook_type prev_ExecutorEndHook = NULL; void _PG_init(void) { prev_ExecutorStartHook =

[HACKERS] Weirdness using Executor Hooks

2015-06-18 Thread Eric Ridge
I've written an extension that hooks ExecutorStart_hook and ExecutorEnd_hook. The hooks are assigned in _PG_init() (and the previous ones saved to static vars) and reset to the previous values in _PG_fini(). Maybe also of interest is the extension library is set in postgresql.conf as a

Re: [HACKERS] Weirdness using Executor Hooks

2015-06-18 Thread Eric Ridge
On Thu, Jun 18, 2015 at 5:30 PM, Tom Lane t...@sss.pgh.pa.us wrote: If that's broken, then so are most of our contrib modules. Certainly none of them have an extra check as suggested by Andres. I'm putting it in anyways, along with a guard in the actual hook function to ERROR if prev_hook ==

Re: [HACKERS] Weirdness using Executor Hooks

2015-06-18 Thread Eric Ridge
On Thu, Jun 18, 2015 at 5:39 PM, Tom Lane t...@sss.pgh.pa.us wrote: BTW, if it didn't occur to you already --- next time you see this, you could try examining dfmgr.c's DynamicFileList data structure using gdb. That might help illuminate what Postgres thinks it loaded and why. Hmm, okay.

Re: [HACKERS] Weirdness using Executor Hooks

2015-06-18 Thread Eric Ridge
On Thu, Jun 18, 2015 at 6:04 PM, Tom Lane t...@sss.pgh.pa.us wrote: What we were expecting I guess is that such functions would be declared to reference the library underneath $libdir/plugins, not that you'd use a symlink. According to pg_proc.probin, all 32 of my C language functions point

Re: [HACKERS] Change pg_cancel_*() to ignore current backend

2015-05-22 Thread Eric Ridge
On May 19, 2015, at 6:59 PM, Jim Nasby jim.na...@bluetreble.com wrote: I find it annoying to have to specifically exclude pg_backend_pid() from pg_stat_activity if I'm trying to kill a bunch of backends at once, and I can't think of any reason why you'd ever want to call a pg_cancel_*

Re: [HACKERS] Change pg_cancel_*() to ignore current backend

2015-05-22 Thread Eric Ridge
On Fri, May 22, 2015 at 4:51 PM Jim Nasby jim.na...@bluetreble.com wrote: Interesting idea. I suspect that would be even more invasive than modifying the functions though... Here's the solution. I can't see how anyone could possibly disagree with this... ;) Change the sort order for

[HACKERS] Given a view relation OID, how to construct a Query?

2015-12-09 Thread Eric Ridge
I'm doing some extension development (in C) and have a situation where I need to examine the target list of a view, but all I have is the view's oid. An approach that works is (pseudocode): SPI_connect(); "SELECT ev_action FROM pg_catalog.pg_rewrite WHERE rulename = '_RETURN' and

Re: [HACKERS] Given a view relation OID, how to construct a Query?

2015-12-09 Thread Eric Ridge
On Wed, Dec 9, 2015 at 5:07 PM Tom Lane wrote: > > FWIW, it's exposed in 9.4 and up. But in older branches you could > probably just copy it, it's not that big. > That's good to know, thanks. I did copy it and it's almost 3x faster than going through SPI. Thanks again for

Re: [HACKERS] Given a view relation OID, how to construct a Query?

2015-12-09 Thread Eric Ridge
On Wed, Dec 9, 2015 at 4:04 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Eric Ridge <eeb...@gmail.com> writes: > > I'm doing some extension development (in C) and have a situation where I > > need to examine the target list of a view, but all I have is the view's > oid.

Re: [HACKERS] Disallow unique index on system columns

2016-04-21 Thread Eric Ridge
On Wed, Apr 20, 2016 at 9:24 PM Tom Lane wrote: > > SELECT FROM table WHERE my_func('table', ctid) ==> 'index condition' > > Um, why's the ctid important here, or perhaps more directly, what is > it you're really trying to do? > This function is defined as

Re: [HACKERS] Disallow unique index on system columns

2016-04-20 Thread Eric Ridge
On Sat, Apr 16, 2016 at 12:14 PM Tom Lane wrote: > > Pushed. I moved the check into DefineIndex, as that's where user-facing > complaints about indexes generally ought to be. > If you're planning on back-patching this, please don't. :) It'll literally ruin my life. I've

Re: [HACKERS] Example Custom Scan Provider Implementation?

2017-03-08 Thread Eric Ridge
On Tue, Mar 7, 2017 at 6:39 PM Amit Langote wrote: > > Here you go: https://github.com/kaigai/ctidscan Thanks for the link, Amit! I think that'll get me bootstrapped! This was proposed originally [1] to go into contrib/, but that didn't > happen somehow. > Too

Re: [HACKERS] How to get the 'ctid' from a record type?

2017-03-11 Thread Eric Ridge
On Sat, Mar 11, 2017 at 2:14 PM Andres Freund <and...@anarazel.de> wrote: > On 2017-03-11 04:31:16 +0000, Eric Ridge wrote: > > Well shoot. That kinda spoils my plans. > > I think you should elaborate on what you're trying to achieve - > otherwise our advice will b

[HACKERS] How to get the 'ctid' from a record type?

2017-03-10 Thread Eric Ridge
This is about Postgres 9.6... I have a very simple 1-arg function, in C, that I want to return the ctid of the record passed in. Example: CREATE OR REPLACE FUNCTION foo(record) RETURNS tid LANGUAGE c IMMUTABLE STRICT AS 'my_extension'; Its implementation is simply: Datum foo(PG_FUNCTION_ARGS)

Re: [HACKERS] How to get the 'ctid' from a record type?

2017-03-10 Thread Eric Ridge
> > I suspect the tuple at (0,1) has been the subject of a failed update. > Yep. > Your problem here is that you're mistaking the t_ctid field of a tuple > header for the tuple's address. It is not that; it's really just garbage > normally, and is only useful to link forward to the next

[HACKERS] Example Custom Scan Provider Implementation?

2017-03-07 Thread Eric Ridge
Hi all! Does anyone know of a simple, example Custom Scan Provider implementation for 9.6+? I found pg_strom by searching GitHub. Its gpuscan.c looks like maybe it implements a pattern similar to what I want to do, but there's a lot of extraneous (to me) stuff to parse through. I'm kinda

Re: [HACKERS] How to determine that a TransactionId is really aborted?

2017-10-22 Thread Eric Ridge
> On Oct 22, 2017, at 1:50 PM, Peter Geoghegan <p...@bowt.ie> wrote: > > On Sun, Oct 22, 2017 at 12:23 PM, Eric Ridge <eeb...@gmail.com> wrote: >> Can anyone confirm or deny that this is correct? I feel like it is correct, >> but I'm no expert. > > Wh

[HACKERS] How to determine that a TransactionId is really aborted?

2017-10-22 Thread Eric Ridge
When sitting inside an extension, and given an arbitrary TransactionId, how can you determine that it aborted/crashed *and* that no other active transaction thinks it is still running? I've tried to answer this question myself (against the 9.3 sources), and it seems like it's just: {

Re: [HACKERS] How to determine that a TransactionId is really aborted?

2017-10-22 Thread Eric Ridge
> On Oct 22, 2017, at 3:24 PM, Peter Geoghegan <p...@bowt.ie> wrote: > > On Sun, Oct 22, 2017 at 2:19 PM, Eric Ridge <eeb...@gmail.com> wrote: >> I'm looking for the status as any concurrent open transaction might see it. >> For example, if any

Re: [HACKERS] How to determine that a TransactionId is really aborted?

2017-10-22 Thread Eric Ridge
> On Oct 22, 2017, at 2:50 PM, Jaime Casanova > wrote: > > so, what you want is txid_status() [1]... while this is new in v10 you > can use the code as guide or just migrate to v10 ;) Oh neat, thanks. Doesn't that tell you the status relative to the