2011/10/31 Christopher Browne :
> There is legitimate reason to reject this on the basis of nondeterminism.
>
> While we are surely obliged to "hold our noses" and support "SELECT *", as:
> A) The SQL standard obliges us, and
> B) People already use it a lot,
>
> Neither of those factors hold true
On Sun, Oct 30, 2011 at 11:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'd like to propose the attached patch, which initializes each
>> PGPROC's myProcLocks just once at postmaster startup, rather than
>> every time the PGPROC is handed out to a backend. These lists should
>> always be empt
Robert Haas writes:
> I'd like to propose the attached patch, which initializes each
> PGPROC's myProcLocks just once at postmaster startup, rather than
> every time the PGPROC is handed out to a backend. These lists should
> always be emptied before a backend shuts down, so a newly initialized
>
There is legitimate reason to reject this on the basis of nondeterminism.
While we are surely obliged to "hold our noses" and support "SELECT *", as:
A) The SQL standard obliges us, and
B) People already use it a lot,
Neither of those factors hold true for the EXCLUDING notion. So all things
are
> 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 Sun, Oct 30, 2011 at 6:11 PM, Darren Duncan wrote:
> Eric Ridge wrote:
>>
>> I don't actually like the term "EXCLUDING", but it conveys what's
>> happening and is already defined as a keyword. I thought about
>> "EXCEPT", but that doesn't work for obvious reasons, and "NOT" might
>> just be co
Mark Mielke wrote:
On 10/30/2011 03:50 PM, Eric Ridge wrote:
Changes of omission can break your code just as easily.
I think I wasn't as clear as I intended. In many ways, I think use of
"*" in the first place is wrong for code (despite that I do it as well).
Therefore, "* EXCLUDING (...)" w
On Sun, Oct 30, 2011 at 7:46 PM, Mark Mielke wrote:
> In the above case - maybe you don't want password - what about social
> insurance number, credit card number, or any other private bit? The only way
> to truly know you aren't accidentally pulling in fields you don't need or
> want to unnecessa
On 10/30/2011 03:50 PM, Eric Ridge wrote:
On Sun, Oct 30, 2011 at 3:38 PM, Mark Mielke wrote:
2) Not deterministic (i.e. a database change might cause my code to break),
Okay, I'm inventing a use-case here, but say you have a "users" table
with various bits of metadata about the user, includin
I'd like to propose the attached patch, which initializes each
PGPROC's myProcLocks just once at postmaster startup, rather than
every time the PGPROC is handed out to a backend. These lists should
always be emptied before a backend shuts down, so a newly initialized
backend will find the lists em
On Sun, Oct 30, 2011 at 3:17 PM, Tom Lane wrote:
> "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)
I don't know what
Eric Ridge wrote:
I don't actually like the term "EXCLUDING", but it conveys what's
happening and is already defined as a keyword. I thought about
"EXCEPT", but that doesn't work for obvious reasons, and "NOT" might
just be confusing.
How about "BUT"?
Is that already in use by something? Its
On Sun, Oct 30, 2011 at 4:43 PM, Darren Duncan 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 excluding multiple col
Eric Ridge wrote:
On Sun, Oct 30, 2011 at 4:03 PM, Tom Lane 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 aster
On 10/30/2011 04:03 PM, Tom Lane wrote:
Please correct me if I'm wrong, but if we choose the word carefully
(which is why I chose EXCLUDING), I think we're okay? EXCLUDING is
already defined as an "ordinary key word".
Yeah, it's unreserved so it doesn't break use of the same name for
column
On Sun, Oct 30, 2011 at 4:03 PM, Tom Lane 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 asterisk in the "target
Eric Ridge writes:
> On Sun, Oct 30, 2011 at 3:38 PM, Mark Mielke wrote:
>> 2) Not deterministic (i.e. a database change might cause my code to break),
> Okay, I'm inventing a use-case here, but say you have a "users" table
> with various bits of metadata about the user, including password.
> Ma
Eric Ridge writes:
> On Sun, Oct 30, 2011 at 3:17 PM, Tom Lane wrote:
>> In particular, I don't think it's acceptable to introduce a
>> new reserved keyword for this --- that would fall under the "fails to
>> not break anything else" category.
> Please correct me if I'm wrong, but if we choose t
On Sun, Oct 30, 2011 at 3:38 PM, Mark Mielke 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 I'm too laz
Stupid question:
Is this just a display thing? Or does this have impact for things such
as COUNT(*) vs COUNT(1)?
Is it "like a view, but on the fly"?
I'm found myself in the *occasional* (certainly not daily!) situation
where such a feature might be useful, but each time I wonder about if
t
Tom Lane wrote:
Darren Duncan writes:
The real question to ask ourselves is, if Eric Ridge is willing to do all the
work to implement this feature, and the code quality is up to the community
standards and doesn't break anything else, then will the code be accepted?
It's entirely possible th
On Sun, Oct 30, 2011 at 3:17 PM, Tom Lane 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 --- that would f
David Wilson wrote:
On Sun, Oct 30, 2011 at 1:10 AM, Darren Duncan wrote:
The SQL level is exactly the correct and proper place to do this.
Its all about mathematical parity. That is the primary reason to do it.
- "SELECT *" gives you a whole set.
- "SELECT foo, bar" gives you a subset of t
On Sun, Oct 30, 2011 at 2:54 PM, Robert Haas 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 there,
the "target_el" ru
Darren Duncan writes:
> The real question to ask ourselves is, if Eric Ridge is willing to do all the
> work to implement this feature, and the code quality is up to the community
> standards and doesn't break anything else, then will the code be accepted?
It's entirely possible that it will get
I think the loose consensus I've picked up from people in this thread is that
the ability to tersely specify a complementary subset of columns is something
that is simple enough and wouldn't hurt us to have it but that its utility is
limited such that a lot of people wouldn't want to do the work
On Oct 30, 2011, at 11:54 AM, Robert Haas wrote:
>> If you know that you want all fields except X, Y and Z, why should you be
>> forced to manually cut and paste all the other fields into the view
>> definition? That's wasted time and effort that could better be spent
>> elsewhere.
>
> I agree
On Sun, Oct 30, 2011 at 2:15 PM, Jim Nasby wrote:
> If you know that you want all fields except X, Y and Z, why should you be
> forced to manually cut and paste all the other fields into the view
> definition? That's wasted time and effort that could better be spent
> elsewhere.
I agree. This
On Sun, Oct 30, 2011 at 10:58 AM, Tom Lane wrote:
> You are misreading the old code. The inner loop increments the last
> byte, checks for success, and if it hasn't produced a greater string
> then it loops around to increment again.
Ugh. You're right.
--
Robert Haas
EnterpriseDB: http://www.
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 dat
On Oct 29, 2011, at 11:53 PM, Joshua D. Drake wrote:
> On 10/29/2011 03:26 PM, Eric Ridge wrote:
>>
>> 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
>>
Hi.
I tested that make 3.82 - win32 version hasn't any new functionalities
for example .ONESHELL.
--
pasman
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Oct 30, 2011 at 1:51 PM, Eric B. Ridge wrote:
> eric
>
> PROPRIETARY AND COMPANY CONFIDENTIAL COMMUNICATIONS
my bad. Switched email accounts without realizing. :(
eric
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
Robert Haas writes:
> On Sat, Oct 29, 2011 at 4:36 PM, Tom Lane wrote:
>> Oh! You are right, I was expecting it to try multiple characters at the
>> same position before truncating the string. This change seems to have
>> lobotomized things rather thoroughly. What is the rationale for that?
>>
On Sat, Oct 29, 2011 at 08:28:57PM +, Mr. Aaron W. Swenson wrote:
> > If /tmp is the only decent place where to put the socket file on Unix
> > when security and other concerns are considered, then sure, making
> > distro life difficult is a good thing to do. But then let's take it to
> > the F
Sorry, I forgot to include the version used & some information about my setup:
PostgreSQL version: Git HEAD as of:
Date: Fri Oct 28 21:18:36 2011 -0400
Commit: 51eba98cf4595e90730dedd9305da8aa84b649ee
Compiled with defaults, (only change --with-pgport = 5431). I used default
settings, shared_buf
Quoting Robert Haas:
"""
I tried this on my MacBook Pro this morning, using pgbench -i -s 500
to create a database about 7.5GB in size, and then using "SELECT
sum(1) FROM pgbench_accounts" as a test query, on a build WITHOUT
--enable-cassert. This machine has 4GB of memory, and I set
shared_buffer
On Sun, Oct 30, 2011 at 1:10 AM, Darren Duncan wrote:
> The SQL level is exactly the correct and proper place to do this.
>
> Its all about mathematical parity. That is the primary reason to do it.
>
> - "SELECT *" gives you a whole set.
> - "SELECT foo, bar" gives you a subset of that.
> - "SEL
Pavel Stehule wrote:
2011/10/30 Darren Duncan :
I agree that this feature would be quite useful and should be included in
SQL. The exact syntax is less of an issue, but just the ability to cleanly
say "select all columns except for these". I have in fact argued for the
same feature in the past.
39 matches
Mail list logo
