Re: [HACKERS] pg_dump --split patch
On Tue, Dec 28, 2010 at 2:39 PM, Joel Jacobson wrote: > > I think you are right about functions (and aggregates) being the only > desc-type where two objects can share the same name in the same schema. > This means the problem of dumping objects in different order is a very > limited problem, only affecting overloaded functions. > > I didn't include the arguments in the file name, as it would lead to very > long file names unless truncated, and since the problem is very limited, I > think we shouldn't include it. It's cleaner with just the name part of the > tag in the file name. > Why not place all overloads of a function within the same file? Then, assuming you order them deterministically within that file, we sidestep the file naming issue and maintain useful diff capabilities, since a diff of the function's file will show additions or removals of various overloaded versions. -- - David T. Wilson david.t.wil...@gmail.com
Re: [HACKERS] Thoughts on "SELECT * EXCLUDING (...) FROM ..."?
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. > - "SELECT ALL BUT foo, bar" gives you the complementary subset. That's not actually entirely true given the usual SQL (and mathematical) meaning of "set". This feature relates to the set of attributes returned regarding elements of the returned set, not the set itself- the actual returned set is identical regardless of the column-specifier formulation. Claiming this as an SQL mathematical purity issue is a bit disingenuous, as SQL set manipulation takes place at the member level rather than the attribute level- SQL is otherwise quite explicit about requiring explicit listings of the attributes that the client is interested in regarding a returned set of member rows. > > Arguing against this is like arguing against a subtraction operator, because > we can emulate using addition plus negation, or saying subtraction should > just be a special filter in a client app. That would be true if this was an argument against "WHERE" or "EXCEPT". Column specification and row specification are very different and cannot be conflated. That's not to say this proposal is without merit, merely that your arguments for it are poorly founded and not particularly relevant. -- - David T. Wilson david.t.wil...@gmail.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
