Re: Odd procedure resolution
От | Peter Eisentraut |
---|---|
Тема | Re: Odd procedure resolution |
Дата | |
Msg-id | 38e82413-45c2-b858-05d4-c11ab4a7b54a@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Odd procedure resolution (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 5/17/18 16:54, Tom Lane wrote: > TBH, this is several months too late for v11. Maybe, but ... You're talking about a > really fundamental redesign, at least if it's done right and not as a > desperate last-minute hack (which is what this looks like). The points > you make here are just the tip of the iceberg of things that would need > to be reconsidered. I disagree with that assessment. The patch is large because it reverts some earlier changes. But I think the new setup is sound, in large parts cleaner than before, and addresses various comments that have been made. I leave it up to the community to decide whether we want to address this now or later. One thing to take into consideration is that leaving things as is for PG11 and then making this change or one like it in PG12 would create quite a bit of churn in client programs like psql, pg_dump, and probably things like pgadmin. > I also remain of the opinion that if we're to separate these namespaces, > the way to do that is to put procedures somewhere other than pg_proc. That would just create an unfathomable amount of code duplication and mess and unnecessary extra work in PL implementations. > Unless you can show that "separate namespaces" is the *only* correct > reading of the SQL spec, which I doubt given the ROUTINE syntax, > I think we're pretty much stuck with the choice we made already. I have apparently read the SQL standard differently at different times. Are you asking me whether I think my current reading is more correct than my previous ones? Well, yes. But someone else should perhaps check that. Start with the syntax rules for <SQL-invoked routine>. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: