If this communication is in fact intended to be protected by some
legal privilege, or to remain company confidential, you have
definitely sent it to the wrong place.
Sadly I don't control my company's email server. They however don't control my
gmail account. I'll switch to that.
eric
On Nov 1, 2011, at 6:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I can think of a number of places where you can write * where I'm
pretty sure we *don't* want this. It should be restricted to top-level
entries in SELECT targetlists, IMO.
Yes. That is the exact conclusion I've come to.
On Oct 30, 2011, at 12:53 AM, Joshua D. Drake wrote:
If it is quite regular I would actually argue two things:
1. Use a view
2. You haven't normalized correctly
I am not trying to be a pedantic zealot or anything but those would be my
arguments against.
You know how general database
The exact choice of keyword matters
a lot less than whether this can be done with out shift/reduce or
reduce/reduce conflicts.
Which is the problem right now. See my other email.
I'll post a diff tomorrow. Maybe if enough folks think is a feature worth
having we can find a solution. My
On Jan 21, 2010, at 12:35 PM, David E. Wheeler wrote:
And where do you think baby powder comes from? Sheesh.
You won the thread!
eric
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct 19, 2009, at 2:47 PM, Tom Lane wrote:
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory
default,
at least for a few releases, will be throw-error.
Sorry if this is obvious to everyone else, but *when* will the
On Oct 19, 2009, at 3:46 PM, Tom Lane wrote:
Sorry if this is obvious to everyone else, but *when* will the error
throw?
Whenever we do semantic analysis of the particular query or
expression.
That's what I figured.
During CREATE FUNCTION or during runtime? I'm secretly hoping
that
On Oct 13, 2009, at 11:02 AM, Dave Page wrote:
A useful feature found in other DBMSs such as MS SQL Server that has
been requested on these lists a few times, is the ability for a client
application to report its name to the server.
I've been following this thread closely and haven't seen
On Oct 14, 2009, at 12:39 PM, Dave Page wrote:
Isn't that cluttered enough already?
I find the ps output uninformative. Having it display something that
gets generated from my application would start to make it useful.
Maybe what I really want is a totally different feature:
On Jul 26, 2009, at 6:46 PM, David E. Wheeler wrote:
Is there some way to get using_while() to properly return all the
records?
I'm just a random lurker, but FOUND seems to work just fine (I suppose
it's PG-specific?).
On Apr 22, 2009, at 10:47 PM, Tom Lane wrote:
I think this is due to a change that was made in 8.2:
Cool. Thanks for the followup!
eric
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Apr 20, 2009, at 2:27 PM, Eric B. Ridge wrote:
Some investigation showed that the use of non-IMMUTABLE PL/PGSQL
functions as view columns, when these views are joined with other
views, cause the query to be planned poorly.
I'm sorry. I should have said VOLATILE functions. Which
I loaded a copy of a production database into PG 8.4b1 and immediately
saw that all of our queries were significantly slower compared to v8.1.
Some investigation showed that the use of non-IMMUTABLE PL/PGSQL
functions as view columns, when these views are joined with other
views, cause the
I just wanted to give you guys a virtual pat on the back for PG
v8.4dev. I've been out of the computer world for a little over a year
and we're still using v8.1 here where I work, so I'm a little behind
the changes timeline since v8.1, but v8.4 is looking very nice.
I'm working on
With pg v7.4.7 I've written an SRF that uses SPI to return the results
of a query. It's one of those functions that works perfectly for me in
development but randomly crashes in production. Thus far I've been
unable to reproduce the crash. The problem is surely in my code. And
before I dig
On Nov 5, 2004, at 7:09 AM, John Hansen wrote:
Attached, array - rows iterator.
select * from unnest(array[1,2,3,4,5]);
This is really handy! But there is a problem...
The switch statement could probably be done in a different way, but
there doesn't seem to be any good examples of how to return
On Jan 18, 2004, at 7:28 PM, Tom Lane wrote:
Theory B would be that there's some huge overhead in calling
non-built-in functions on your platform.
I've done some profiling and convinced myself that indeed there's
pretty
steep overhead involved in fmgr_info() for a C-language function.
Much of it
On Sep 27, 2003, at 3:43 PM, Tom Lane wrote:
Eric Ridge [EMAIL PROTECTED] writes:
I don't think the OS X 10.3 betas are readily available (I've payed to
be in Apple's developer program), so if you don't have access to 10.3
but have some idea as to what would cause this problem with tas, I'll
do
On Saturday, March 8, 2003, at 11:54 PM, Justin Clift wrote:
Tom Lane wrote:
snip
2. Consider this Apple's problem and file a bug report.
Is there a good place to report errors to Apple for this kind of thing?
The best place I can find is:
http://developer.apple.com/bugreporter/index.html
I've been following this thread, and I thought this might be a good
place and time to throw in a few additional feature requests.
What about expanding the history capabilities of psql's history command
(\s) to include something more bash/tcsh-like? For example:
!insert
-- execute the
20 matches
Mail list logo
