Pavel Stehule wrote:
2011/10/30 Darren Duncan dar...@darrenduncan.net:
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
On Sun, Oct 30, 2011 at 1:10 AM, Darren Duncan dar...@darrenduncan.net 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
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_buffers =
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,
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 FHS that
Robert Haas robertmh...@gmail.com writes:
On Sat, Oct 29, 2011 at 4:36 PM, Tom Lane t...@sss.pgh.pa.us 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.
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
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 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
the columns
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
On Sun, Oct 30, 2011 at 10:58 AM, Tom Lane t...@sss.pgh.pa.us 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
On Sun, Oct 30, 2011 at 2:15 PM, Jim Nasby j...@nasby.net 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
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. This
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
Darren Duncan dar...@darrenduncan.net 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
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
David Wilson wrote:
On Sun, Oct 30, 2011 at 1:10 AM, Darren Duncan dar...@darrenduncan.net 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
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
Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net 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?
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
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
Eric Ridge eeb...@gmail.com writes:
On Sun, Oct 30, 2011 at 3:17 PM, Tom Lane t...@sss.pgh.pa.us 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
Eric Ridge eeb...@gmail.com writes:
On Sun, Oct 30, 2011 at 3:38 PM, Mark Mielke m...@mark.mielke.cc 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
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
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
columns
Eric Ridge wrote:
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
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
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 nice
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)
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
On 10/30/2011 03:50 PM, Eric Ridge wrote:
On Sun, Oct 30, 2011 at 3:38 PM, Mark Mielkem...@mark.mielke.cc 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
On Sun, Oct 30, 2011 at 7:46 PM, Mark Mielke m...@mark.mielke.cc 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
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 (...)
On Sun, Oct 30, 2011 at 6:11 PM, Darren Duncan dar...@darrenduncan.net 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
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
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
Robert Haas robertmh...@gmail.com 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
On Sun, Oct 30, 2011 at 11:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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.
2011/10/31 Christopher Browne cbbro...@gmail.com:
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
39 matches
Mail list logo
